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