On 05/03/2008, Elijah Newren <[EMAIL PROTECTED]> wrote: > On Wed, Mar 5, 2008 at 3:37 AM, Olav Vitters <[EMAIL PROTECTED]> wrote: > > > I add to that: Have entire project history offline. Or at least have a > > > usable option to do so. > > > > Isn't that with any DVCS? > > > No, it's not. bzr does not have this ability. See > > http://blogs.gnome.org/newren/2007/11/24/local-caching-a-major-distinguishing-difference-between-vcses/ > > If you want just the history of a single branch, then bzr, hg, and git > will meet your needs. If you want all history (I certainly do), then > bzr falls far short. It's a Repository Formats Matter thing too, so > don't expect to see bzr obtain this ability anytime soon.
I think you are mischaracterising Bazaar's functionality here. A Bazaar branch contains the entire history of that branch. If I merge some other branch into my one, then all the information necessary to reconstruct any of those revisions will be present in my branch (so I can diff against them, branch off them, etc). So what you get is essentially the same information as if you pulled a single head from one git repository to another. If I want to track multiple heads at once, I pull multiple branches. If my copies of those branches reside in the same repository, they will share storage similar to when you manage multiple heads in a single git repository. There is the UI difference that the default "pull" commands of bzr and git do different things (pull a single head versus pull a collection of heads), but that has nothing to do with repository formats. Could you elaborate on what repository feature you're referring to? > > Does it always get the whole history? Others allow e.g. only doing a > > minimal checkout and using the remote server for missing info (saves > > lots of diskspace).. that is bzr.. Hg I still need to investigate (I > > really hate that file merge thingy). > > > bzr provided super shallow checkouts first, i.e. just a working copy. > However, git did one up on them and allowed the user to download > "shallow" histories--anywhere between 0 and n commits. bzr then > copied git's pack idea in the past couple months, in order to obtain > this feature and some of git's performance characteristics. (Let me > also note that bzr has a number of nice UI abilities not found > elsewhere with such a checkout, allowing users to essentially operate > in a centralized mode.) While this sounds cool, it really isn't all > that useful because: Shallow branch support for Bazaar is currently in development, and should be available in a few releases. From Robert's initial tests, he was able to create usable branches that contained only the local changes, with a reference to another branch for the remaining history. So if I make a one line fix to a project with a 100MB working tree size, the shallow branch size will be proportional to the 1-line file rather than the 100MB tree. Of course, such a repository is useless if you can't reach the base branch/repository containing the rest of the data. It could be useful if developers want to publish their own personal branches on a gnome.org server without us running out of disk space: If both the base repository and the developer's reopsitory branch are on the same machine then it should be as reliable as two full-history repositories. > Your assertion that shallow checkouts saves lots of diskspace is not > well founded in my experience. It was certainly true of bzr when bzr > originally first implemented the feature, but these days systems are > able to get a full copy of the history plus a working copy and STILL > often take less space than an svn checkout. Source code and its > changes over time compresses really well with smart algorithms. The main reason why I use lightweight checkouts with Bazaar in my day to day development are: 1. I like to keep my repository data separate from my working trees. This makes backup easier, and I can blow away a working tree with no danger of losing information (assuming I've committed everything I wanted to). 2. I can switch the working tree over to another branch. This is useful if I come up with a bug fix while working on something else, it is trivial to switch the working tree to another branch, commit, then switch back. I assume you do something similar with git. 3. While a working tree plus the entire history might be of similar size to a Subversion working copy, I sometimes want to work on two lines of development separately. Sharing the history between the two working copies is a definite win. 4. If I have no working tree for an old branch that I've merged, then its storage requirements are a small constant value. > > Hrm. Don't understand why all those commands have to have a different > > meaning in Git. Reset that isn't reset, etc. > > > I agree with the general sentiment, but the specific case is not > correct...there is no reset command in cvs, svn, hg, or bzr, so I > think git was free to use reset for something new...as they did. > > I will note that a subset of the functionality from git checkout and > git reset often get confused with git revert. Another nasty unneeded > UI wart (that is surprisingly easy to fix I might add...). "git reset" sounds a lot like "bzr uncommit" is that accurate? James. _______________________________________________ Gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
