Selon Markus Schiltknecht <[EMAIL PROTECTED]>: > (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. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel