Revision storage question

Angela seasonalplume at
Thu Feb 8 02:55:40 GMT 2007

On 2/8/07, John Arbash Meinel <john at> wrote:
> > Thanks for your suggestions. Basically the problem right now is that
> there
> > are a few couple directories that need versioning, and they contain
> binary
> > files. All in all the size right now is up to ~800MB, and I've broken it
> > down to four chunks. Each chunk has a dozen or two subdirectories under
> it,
> > and a still a few under _that_, etc. One could say that it makes more
> sense
> > to create repositories for smaller chunks than the four (i.e., instead
> of a
> > repository for all documentation on a project, you'd have one repository
> > for
> > the technical documentation, another repository for the user's manual,
> etc)
> > although I'm still debating the pros and cons of that one -- looking at
> it,
> > that's a lot of repositories shared over the network.
> They can be put in a fully shared repository, and just have separate
> branches for everything. Clients will only download the portions they
> need. For example:

Thanks! For now that's what I've done, but with trees; that computer is used
as actual file storage as well, so trees worked fine, I think. Right now I



And so on. :) I think this works good for me. I toyed with the idea of
having the whole root of the drive as a shared repository and just define
branches under it, but then I do have a few directories that I don't want
versioned (Installers, Images, personal stuff, etc) and wasn't sure what
impact having those non-versioned directories inside might have on the
shared repository. Additionally, I had already started versioning the Source
folder, with the shared repository on a per-project basis, and wasn't sure
how having a shared repository within another shared repository work (I'm
thinking it wouldn't). Or, how to move history of a repository into a shared

For something like this, it does seem that 'bzr checkout --lightweight'
> may be your best method. This is very much 'SVN' mode, since you don't
> have any history stored locally. (It does mean that you can't commit
> while offline, but that doesn't sound important in your situation).

No, it's not that critical, at least for the documentation part; I'm
planning to do lightweight checkouts for documentation, and then heavyweight
checkouts for source/coding/programming. :) And yes, things have been split
up into smaller, more manageable chunks; I think the biggest at the moment
is 200MB.

I would definitely recommend using 'bzr+ssh://' if you can install bzr
> on your server, as it is already quite a bit faster than sftp, and with
> what has been going on on the 'hpss' branch, it should continue to
> become much better.

I've been reading into the bit of info on the bazaar server yesterday, but
haven't gotten anything conclusive yet about if I'll keep using bzr the way
I'm using it now, or to use the smart server. Right now, to do a checkout on
my laptop, I do:

bzr checkout \\Server\source\project1\devt

(Actually, I'm making a batch file for the less volatile documentation
repositories, but as of the moment that's the sort of command I'm using for
the batch file to retrieve/etc checkouts.)

Would using the smart server be a better option? I can always install it as
a service on the server computer if needed.

(PS. The "server computer" I'm referring to is really basically an ordinary
desktop computer, not an actual server. It has Apache 2.2 plus PHP and MySQL
all that, but it's really for development/storage/everything else purposes.)

Thanks again, you're great help. :D


And I write in my seasonal plume.
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the bazaar mailing list