identical changes conflict
Deliverable Mail <[email protected]> Tue, 22 Mar 2005 10:56:33 -0500
| Newsgroups | gmane.comp.version-control.bitkeeper.user |
|---|---|
| Message-ID | <[email protected]> |
As I described before, I test an SCM Carnival setup where several distributed SCMs, such as tla, darcs, and bk, coexist in the same directory. Update/commit/pull cycle involves calling each SCM's corresponding command in sequence. Commit is not a problem, as changes route into their respective SCMs' separate auxiliary subdirectories. Pulls, however, do conflict -- the first SCM gets to pull nicely, changing the sources themselves properly as well as its own auxiliaries. The remaining SCMs, however, detect a conflict in the modified sources -- since it turns out they don't check for the case WHERE THE CHANGES ARE IDENTICAL. Probably it's not typical in common non-automated use, but I wonder what's the reasoning there. In case you don't follow all that mumbo-jumbo with multiple SCMs, here's a simple, purely bk case. Create a local repo and mirror it in a remote repo. Create a text file in one repo and sync it into another. Now do this: add a line to the file in the local repo and commit. Then go to the remote, ADD THE SAME LINE MANUALLY BEFORE SYNCING, so that the files are now in fact identical in source but not as recorded in the auxiliary bk directories. Now bk pull cannot do it job, saying SCCS/s.file is edited. If bk were to check that the result of aplying the patch to the last commit would indeed yield the new local file identical to the one present, perhaps it might see there's no conflict and not bother with it? At least I'd love to see an option to tell it that's the case, in the sense of --auto-resolve-identical or some such. Cheers, Alexy