Comments on: Directory renaming in SCM

By: Manuel Bua

Manuel Bua — Thu, 24 Dec 2009 19:03:18 +0000

* reformulating the “non-fast-fordward push” case *

dev-b get a non-fast-forward push condition in the case dev-a pushed the rename change but dev-b pulled from the origin previously than dev-a completed the its push: in that case, a pull/fetch request by dev-b is needed to bring in the remote commit and notice the rename thing.

By: Manuel Bua

Manuel Bua — Thu, 24 Dec 2009 18:10:28 +0000

Your git version of the test indeed produce the unexpected result of having 2
directories instead of one, dir-b.
While this is true, as far as the git-test.sh script is concerned, this doesn’t
mean this is the way git is meant to be used with multiple developers.
I don’t know what about other SCM, but what i instantly recognized is that the
testcase doesn’t mimic at all a multi-dev workflow, but instead it’s mimic-ing 3
developers working on the very same *local repository* and this can be very well
the culprit for the “wrong” result.
In fact, having 3 devs and everyone of them working on their own local repo does
not produce the problem, but instead, in the case “Developer A” have not pushed
the rename change yet (or “Developer B” doesn’t update his repo), “Developer B”
will be denied to push his changes upstream and he’ll need to resolve them.
As you may know these are “non-fast-fordward pushes” and are there just to prevent
any attempt at overwriting others’ changes: of course git offers you the way to
force it too, but that should be avoided.

By: Ringo De Smet

Ringo De Smet — Mon, 24 Aug 2009 14:45:53 +0000

I have converted the scripts to use shUnit2, with the intent of adding additional use cases. The original sources and all the changes I did so far can be tracked here:

https://bitbucket.org/ringods/scm-correctness/overview/

By: Hinrik Örn Sigurðsson

Hinrik Örn Sigurðsson — Mon, 06 Apr 2009 23:35:06 +0000

I can see how Git might be viewed as doing the wrong thing here. I can also see how your expected outcome would be confusing to others, even downright harmful.

Since Git tracks /content/, it only tracks files, not directories. Directories only exist as part of a file’s path, as far as Git is concerned. So when you do “git mv dir-a dir-b” to move/rename a directory, you’re just changing the paths of all the files contained in dir-a. The fact that there’s nothing left in dir-a after this operation makes no difference to Git. That is, if you had done “mkdir dir-b && git mv dir-a/* dir-b/ && rmdir dir-a” the result would have been the same.

Now, in your example, you merge a branch that moved all files in dir-a to dir-b, you then merge a branch that created a new file in dir-a before the move had happened. It should seem obvious now that the way Git handles this is quite logical. It does not move the new file in dir-a over to dir-b automatically. It would be potentially dangerous to have Git do that by default. How can Git know that it won’t break anything? It can’t know whether the author of the file planned for it to be moved freely. The author may have made changes in other files that expect this file to be where he put it, etc. For this reason I think Git should definitely not move files around like that. In DVCSs where directories are tracked specially (not the case with Git, don’t know about Bazaar or Darcs), this situation should be considered a conflict to be resolved, for the same reasons.

By: Pete

Pete — Tue, 23 Sep 2008 08:00:22 +0000

Trying this with git now (v1.6.0), it produced a merge conflict.

From ../a
* branch master -> FETCH_HEAD
error: Untracked working tree file ‘dirc/bar.txt’ would be overwritten by merge.
fatal: merging of trees ef348a6d2cc53769cd511d2328da08b94b27d928 and 19bf81ec83d14c2b5151fc89ee5f470b3a2ed88b failed
Merge with strategy recursive failed.

By: James

James — Thu, 17 Jan 2008 09:11:10 +0000

Darcs2 still has a ton of problems. Including ridiculous RAM usage and O(something-large) algorithms.

I have a darcs repo with 1900-ish patches in it and I want to move to git. However, tailor/darcs2git/etc need to be able to perform a ‘darcs pull’ one patch at a time. Darcs2 (or darcs 1) cannot even complete pulling the first patch in the repo. I have a machine with 4GB RAM and darcs runs out of memory.

I cannot run annotate on files in my repo either, which is part of the reason I want to dump it – my history has become useless. And unless I can get my history into something else, it’s all gone forever. (or until someone can lend me a machine with much more RAM than I have!)

Darcs is not suitable for production use if you care about your history. Learn git/hg/bzr/monotone – they are all infinitely more reliable, albeit not quite as simple to use.

Apologies for the rant.

By: Dale

Dale — Tue, 01 Jan 2008 21:13:57 +0000

I realize this is old, but I went ahead and wrote a test for Monotone: http://www.codefu.org/people/darkness/mtn-test.sh.txt

Monotone 0.38 seems to do the right thing here. I also went out of my way to do extra work to more closely simulate multiple developers working off of multiple DBs, which is probably unnecessary (I think you could simulate this and see the same results using a single DB).

By: Brock

Brock — Tue, 01 Jan 2008 19:54:36 +0000

Clarification — Darcs2 is _going_ to come out. It is currently out as a release candidate, but still undergoing testing and some development.

I use the current darcs on smaller projects all the time and enjoy it greatly. I’m looking forward to being able to recommend darcs2 for projects of all sizes.

By: Justin George

Justin George — Tue, 01 Jan 2008 03:53:12 +0000

m–s:
sooo… the reality is: darcs is not yet ready for production use (but I really REALLY do hope it will be)

Darcs 2 came out and largely alleviated those bugs. As it stands, only windows compatibility is really a problem if you hate cygwin.

By: Paul

Paul — Mon, 10 Sep 2007 02:47:22 +0000

Here’s a Mercurial version of the script: http://dpaste.com/19091/