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

Re: This is a major issue - much more than a bug!!!

From: Ben Fritz <fritzophrenic_at_gmail.com>
Date: Thu, 28 Feb 2013 14:31:07 -0600

On Thu, Feb 28, 2013 at 1:24 PM, OWENS, RALPH <ro6690_at_att.com> wrote:
> Hi Ben/Bob,
> You've missed my point.
> I understand that keeping up is good. I understand that I didn't keep up and have some responsibility for my mess.
> What I'm unhappy about is the total inability in Tortoise/SVN to clean the mess up. It shows these treeConflicts and you do exactly what it tells you to do and it remains in treeConflict. That is unacceptable.
> There has got to be a way (I think editing the Folders would work) to clean a mess like this.

My suggestion for cleanup is to do lots of little merges instead of
one big merge. By "go back in time" I only meant in terms of revision
numbers. Each incremental change should be fairly trivial to merge. In
the worst case you will need to merge each revision separately but
probably you can do it all in only a few merges, each one getting you
closer to your desired end state.

I agree that tree conflicts are annoying. I hate getting notified on a
merge that my branch and the branch I'm merging both deleted the same
file and OMG WHAT DO YOU WANT TO DO? I feel like kicking SVN at that
point; it's fairly obvious the file should be deleted.

> PS: What I did was abandon myBranch. I created myNewBranch from theirBranch and then manually copied the HeadRevision from myBranch into myNewBranch and went on my way. That gets me able to work again, but unless I look at myBranch, I've lost the history.

You could have done an svn delete on the existing files and then an
svn copy (with history) for your own files to retain your history.

I'd personally be more worried you're overwriting changes somebody
else made this way.

> For a tool upon which I rely, that is an unacceptable work around. I'll do it this time and keep things cleaner to (hopefully) avoid this nonsense in the future.

I agree this workaround is not acceptable. I agree that tree conflicts
could be much better handled; indeed they are much better handled in
both ClearCase and modern tools like git and Mercurial, so far as I
know. I don't like the suggestion that the only way to fix this
problem is to avoid it in the first place.

That said, if it happens again, I'd certainly try the incremental
merge method. I do incremental merges whenever I'm faced with a really
complicated merge, in any version control system. The only reason
regular merging from trunk is easier than a big merge at the end, is
that you end up merging a bunch of little changes instead of one big
change. Doing a series of incremental merges at the end accomplishes
almost the same thing.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-28 21:31:32 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.