Revision storage question

[John Arbash Meinel]

Angela wrote:
> Alexander Belchenko <bialix <at> ukr.net> writes:

...

> 
> Hello Alexander,
> 
> Thanks for your detailed reply, it was helpful. :) I understand (and also
> prefer) the issue about committing parts of a project versus certain files in a
> (programming) project -- that's what I'm doing as of the moment. But for this
> "new" repositories I'm thinking of doing, they're not a project but files, like
> documentation, user manuals, etc. that don't need to be very well knit with the
> rest (although the issues you brought up were still quite sound).

I think the same process still make sense. You still make changes in
terms of units. Perhaps not as obviously, but you can still break up
changes into "I changed X, then Y, then Z". Some of that is just
discipline, to not do some of X then Y then go back and finish X and
then commit and now you can't separate X from Y. You can always just
commit "changed X and Y", though.

> 
> Actually, I think Bazaar isn't exactly what I'm looking for in this other idea
> "repository" I'm looking at, mostly because these are directories/folders with
> lots of files (majority of them binary files) and to checkout the whole "parent"
> directory in order to work on one file remotely might not be a very good idea.
> I was actually looking at Subversion for this (mostly because of the partial
> checkouts idea) but feel very reluctant to be running two VCSs at the same time,
> plus SVN feels quite a bit more complicated than Bazaar to me -- more
> "permanent", with all the talk about SVN servers and repositories and making
> sure your repository has a filesystem that will stay good a few years down the
> line.
> 
> Angela

You can break things up into a more fine grained set of branches, so
documentation for project 1 is a separate branch then documentation for
project 2.

But whatever the layout we don't really support checking out just one
file/subdirectory of a project like SVN supports. For lots of projects
this is a net consistency win. It is pretty easy to have a tree in a
weird state with CVS/SVN because you committed some files and someone
else committed other (non-overlapping) files.

There is still the issue of needing to download the history for file X
when you are only editing file Y.

There are 2 solutions to this. First you can use a lightweight checkout
(bzr checkout --lightweight). Which won't download the history of files,
and acts more like a CVS/SVN checkout (diff has to connect to the server
to get the old text, commit, log, annotate must connect to the server, etc).

You still have a little bit more overhead than with SVN because you
can't checkout a single file.

The other solution is to have a local shared repository (bzr init-repo
--trees PATH). Whenever you do a checkout/branch underneath PATH it will
store the history files at PATH/.bzr/repository. Which means that you do
still need to download all the history, but only once. You don't have to
download everything for each new checkout, even after getting rid of the
checkout.

John
=:->