Daniel Jomphe's Bookmarks

I believe the main question is which type of projects we would like

be checked out on Windows and Unix we should choose
"core.autocrlf true" as our default.  But if our default are native
Windows projects that will never be checked out on Unix, then we
should not set core.autocrlf by default.

If the primary target is native Windows projects that wants CRLF
in the work tree, you could still set core.autocrlf.  Your
checkouts will be with CRLF.  And someday perhaps somebody may
offer porting that to UNIX and his checkout will be without CR.

So wouldn't the categorization be more like this?

 - "real cross-platform" would want core.autocrlf = true;

 - "native Windows" can work either way;

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

• Experimental branches – creating and destroying branches are simple operations and fast.


• Collaboration between peers made easy.

You see, branches and tags in CVS are different things. But in subversion, they are the same - they are just copies of the trunk into one of those directories. In CVS, these events are temporal... that is, they affect a file at a given point in time. In Subversion, while they still apply to a particular version of a file, branches and tags are spatial... that is, they exist as copies of the trunk, just copied into a specially designated place.

This 'branches' and 'tags' convention in subversion is actually limiting, and somewhat false. Since they are really the same thing, I can modify the contents of a 'tag', which is impossible in CVS. I have come to believe that while this convention is useful for projects converted from CVS, it is misleading, limiting, and harmful for new projects. I want a new convention

As long as I am coming up with a new convention, what other things might I want to address? First, I like to have a place 'close to the code' where management documents like requirements, meeting minutes, and the like can be stored, but these kinds of things rarely (if ever) need to be branched. I also like Maven's convention that allows for directories of different kinds of source to be part of the same project. Taking all this into account, here is my new convention:

/project
  /code
    /head
      /rails
      /java
    /versions
  /design
  /management