更新到旧版本时Subversion中的冲突。 问题似乎是我几天前做的合并。 我应该避免这种合并吗？

Question

I've been coding on a single branch in Subversion for some days. Today I've decided to update to an old revision, buried like 30 revisions ago.

Strangely enough, I got conflicts in one of my files. The only reason I see for a problem with this branch would be a merge -r I did some days ago to make my (at the time) head go back to what it was on an old revision.

So, assuming the problem was with the merge -r , I have 2 questions:

1. I did the -r merge so that I could come back to an old revision and then commit it, such that I could start working on from that point on (I basically wanted to discard my X last commits at the time). Was doing this -r merge the right approach? Should I just have created another branch instead? That's certainly what I'd do with git's logical branches, as that'd be way cleaner, but then again, I don't want to "flood" this subversion repo with branches of mine. Maybe I could just create a branch with the old revision and delete this one?

2. Let's say I'll now correct the conflicts. My initial idea when coming back to this revision was to do a -r merge (again). So if in a week I decide I want to come back again, I'll have conflicts again, right? How to avoid this cycle?

This question can, maybe, be formulated in another way. When doing "try and error" coding (with this I mean that I'll have to "come back" many times), how should I organize my Subversion repo?

Thanks

Answer 1

It looks like you need to do a set of modifications parting from one specific revision, then discard the whole set of revisions, and start all over again, several times. If this is the case then I would recommend creating a new branch for each "attempt" and deleting the whole branch for discarding the modifications, or re-integrate it then delete it when you are happy with the code. I think any other approach will give you "merge headaches", but of course I might be wrong.

Answer 2

Remember that svn's reverse merge isn't a 'rollback and discard' your revisions, it undoes the changes you made to those files to the working copy until the file looks like the desired revision. I've never heard of it producing conflicts (unless you have a local modification in your WC that's not been committed yet?)

The question might be to see what the conflict is, and see if you can tell where and why it appeared.

Using merge -r is a valid way to rollback to a previous revision, but making a new branch is just as valid - that only depends on how you organise your repo and how many branches you have. If you're trashing 30 revisions, then it might be a bit cleaner to create a new branch and delete the old.

If you do a lot of try+error coding, a DVCS might be a better option for you - git allows you to checkin locally as many times as you like and push just 1 changeset upstream, discarding all your 'trial' checkins (effectively rolling them up into 1 change), but like I said, we've never had a rollback problem, even with binary files so look into what that conflict is.