Chris Jerdonek writes:
> You can create multiple files this way. I just verified it. But the
> problem happens with merging. You will create merge conflicts in the
> deleted portions of every split file on every merge. There may be a
> way to avoid this that I don't know about though (i.e. to record that
> merges into the deleted portions should no longer occur).
"hg commit" will do that automatically, but you need to resolve that
conflict once manually. If you also happen to be merging *from* a
feature branch *into* the trunk, you need to close the feature branch.
If it needs more work, close it and make a new branch. Alternatively,
merge from trunk into the feature branch "immediately" to minimize the
accumulation of conflicts. Then the eventual merge back to trunk will
only have "real" conflicts in it.
Note that "immediately" in the sense needed can be done at any time
because what you need to do is merge the revision created by the "hg
cp" operations. If Victor tags with "hg tag unicode-refactored", then
you just do "hg merge -r unicode-refactored", and if you haven't made
any changes to the relevant files, you shouldn't get any conflicts.
If you do, then use "hg revert -r unicode-refactored <file> ...",
followed by "hg resolve --mark <file> ...", then fix other conflicts,
resolve, and commit as usual.
There's no other way to do it that I know of in any VCS because they
all track conflicts at the file level. (It would be straightforward
to generalize git to handle this gracefully, but it would be a hugely
disruptive change. I don't know if Mercurial would be susceptible to
such an extension.)
Specifically, AFAIK this kind of merge conflict will occur:
- if the branch being merged was forked before the "hg cp", and
- for each file in the branch containing changes in the deleted region.
I don't advocate this, just want to make the costs clearer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
