>>> On Thu, Apr 12, 2007 at 1:43 pm, Eli Carter
> eli.carter@commprove.com wrote:
> This should detect the existance of a problem, but does not automate the
> correction.
>
> This detects the merge of deletions where the file being deleted has
> changed.
> This is a little more general than the rename case, since you may have a
> file
> that is just deleted on the branch, but modified on trunk... and it's not
> clear you should still delete the file in that case.
>
> So without further ado, a bash function (watch out for line wrapping):
>
> function advanced_merge(){
> ...
> # For all deleted files, verify that the version deleted on the branch
> is
> # the same version as what is being merged into on trunk. If not, we
> have
> # a conflict.
> ...
> }
>
So this seems like what I thought you meant (the steps 1-3), but adds
notification for which versions are the wrong number and will cause problems.
Correct me if I'm wrong...
> I have not tested this thoroughly... but hope this will get discussion
> moving
> on a client‑side work‑around.
>
> Comments? In particular, does this catch the cases we're interested in?
> Does
> it give false positives?
The problem I see is, how does this address the issues I outlined here:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=64725
..starting with "Also I think there is another problem", for when one is merging
changes from two branches to one, in two steps, before committing, OR for
when propagating a merge a second time, to a 3rd or 4th branch. I think the
version # check simply wouldn't work, in those cases.
So I'm back to the ideas of either:
1) a locking scheme like I originally proposed
2) a real fix for the rename bug.
What am I missing?
Thanks!
-Luke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 12 22:40:32 2007