Re: [Monotone-devel] resolving name conflicts; file suturing vs drop

[Ludovic Brenta]

Selon Markus Schiltknecht <address@hidden>:
> (A challenge for the file resurrection UI: what should mtn do, if the 
> user then wants to resurrect file "foo" from the merged revision? There 
> are two node ids which were named "foo".)

It seems to me that, if the node ids were content hashes, it would solve a lot
of problems. For one thing, creating two identical files would yield the same
node id. For another, creating two different files with the same name on
different branches would become a "simple" content conflict. In the specific
case you mention, it would be possible to distinguish between the two "foo"s
and select which one to resurrect. Of course I may be completely off-base.

Still, I'm very interested in this discussion because I'm having problems with
non-content conflicts in the following real-life scenario.

I have a database where I replicate, via tailor, a Subversion repository in a
"vendor" branch. In the same database I have my development branch where I do
all my work. Occasionally, I add a file in my development branch. In order to
propagate changes to the upstream Subversion repo, I apply patches and commit
manually in Subversion, e.g.

$ mtn diff -r h:vendor -r h:development > /tmp/f.diff
$ svn checkout svm+ssh://svn.upstream.org/trunk
$ cd trunk
$ patch -p0 < /tmp/f.diff
$ svn add foo
$ svn commit -m "merge from development branch"

The problem takes place when tailor next updates the vendor branch in the
monotone database. At that point, the file "foo" appears to have been created
independently in both branches, so I get non-content conflicts. The way I
resolve them is clunky:

$ cd ~src/tailor/vendor # this is the monotone checkout that tailor maintains
$ mtn rm foo
$ mtn propagate development vendor
$ mtn update

In essence I'm mucking around behind tailor's back. Do you guys think there is a
better way, or that using content hashes as node ids would help solve the
problem?

-- 
Ludovic Brenta.