[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: rename overwrites code: this a reasonable interim solution?

From: <lsuvkne_at_onemodel.org>
Date: 2007-04-12 22:40:03 CEST

>>> 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:

..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?


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

This is an archived mail posted to the Subversion Users mailing list.