Daniel Jomphe's Library tagged bazaar →  View Popular

Writing a tool to do something that you want is often quite a simple matter of plugging together a few core commands.

It's simple enough that once a few basic concepts are there, you begin to feel comfortable knowing that the repository just can't wedge, changes can be discarded yet not lost unless you request them to be cleaned up, etc.

Disk might be cheap, but my /home is always full -
git has a separate step for compacting repositories, which
means that delta compression can be far more effective. If
you're a compression buff, think of it as having an arbitrarily
sized window, because when delta compressing git is able to match
strings anywhere else in the repository - not just the file
which is the notional ancestor of the new revision.

This space efficiency affects everything - the virtual memory
footprint in your buffercache while mining information from the
repository, how much data needs to be transferred during "push" and
"pull" operations, and so on. Compare that to Subversion, which
even when merging between branches is incapable of using the same
space for the changes hitting the target branch. The results speak
for themselves - I have observed an average of 10 to 1
space savings going from Subversion FSFS to git.

Ok, so you've already gone and made the
commits locally that you wanted to publish back to the Subversion
server. Perhaps you've even made a collection of changes, revising
each change to be clearly understandable, making a single small change
well such that the entire series of changes can be easily reviewed by
your fellow project contributors. It is now time to publish your
changes back to Subversion.

The command to use is git svn dcommit. The d stands for delta

This is a very strong point for renaming, but it is not necessarily an universal one.

Here is one example of the issue: one developer renaming a directory in his branch, and another adding a file to the original directory in his branch. What happens at the merge ?

- Bazaar renames the directory and puts the new file in the _renamed_ directory.

- Git renames the directory with its files, but keeps the old directory too and adds the new file there.

Bazaar’s behavior certainly is better for C. However it is not universally better.

For example in Java you cannot rename a file without changing its contents. So, moving a file to a directory different from where its author put it will almost certainly break the build.

The bottom line is, both behaviors can seem valid or broken, depending on the case. Neither is perfect. At the very abstract level file renames are _not_ a first-class operation. This is especially apparent in a language like Java.

Content movement is the first class operation. Things like moving functions, etc. The question is how one can handle that and whether the current strategy has a path for improvement. It could be argued that once you commit yourself to explicitly tracking file renames, you are giving up a slew of opportunities for handling the more general cases.

One thing is for certain, a 100% ideal solution is impossible. It would have to be aware of the target programming language _and_ the build environment.

Now now, Mark, no misleading assertions if you please. Mercurial tracks renaming information perfectly. It implements it in a different way than Bazaar, but in fact the technique that it uses is more general than Bazaar’s approach.

As you know, Bazaar requires a file to have a unique identity. If I rename A to B, and you rename A to C, the only possible outcome when we merge is a conflict that results in either B or C, because Bazaar requires there to be a single file afterwards. However, Mercurial reports the possible conflict to you *and* is perfectly okay if you decide that the appropriate response is to keep either one, *or* to preserve *both* B and C.

In the book, I mention a bug (455) with this handling which has subsequently been fixed. I’ve not had a chance to update the book with the current behaviour, but I want to note the fact that it’s fixed here.

Mark Shuttleworth says:

Now now Bos, don’t cry FUD when all you’re getting is constructive criticism! I like Hg, but I think it’s important to version directories like files, because I think this gives the result most people actually expect. I wouldn’t call renaming support “perfect” unless it clearly included support for renaming directories. The principle of least surprise is important, and I think Bazaar best reflects that. Giving everyone an A, B, and C option when most people really expect A is cute but ultimately makes the tool harder to use. As for your example, in neither case did either developer ADD a file, in both cases they renamed the same file, so it seems odd to think that ending up with TWO files is an expected result. I don’t think a limitation of a tool should be sold as a feature