Archie Cobbs wrote:
Blair Zajac wrote:
I ended up with a bad merge, that is, the merge committed but it did
not contain the entire commit that was the source of the merge.
This happens when you do:
1) Add a file on a trunk.
2) Commit the file.
3) Run svnmerge.py on the branch.
4) Do a recursive revert: svn revert -R .
5) DO NOT delete the newly added file in the branch.
6) Re-run svnmerge.py to merge the same commit.
In this case there should have been a "Skipped 'some/file'" message that
was output. That is supposed to alert to you that the merge is incomplete.
Yes, there was.
I agree the behavior is less than optimal, but in theory this is
"known behavior" .. part of the "user interface" of svnmerge is that
you must observe the output for any red flag messages... of course,
these happen in other normal cases, such as a merge of a commit which
modifies a file that got added in a previous but yet-to-be-merged
revision.
Granted, it's known behavior, but part of svnmerge.py is to prevent mistakes
like this.
On large merges, you could easily miss this line if you're not paying attention.
So I would like to see svnmerge.py handle this case, either by checking for
stray files in the working copy or parsing the 'svn merge' output.
Comments on either approach?
Regards,
Blair
_______________________________________________
Svnmerge mailing list
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge
