Mark Gritter (markgritter) wrote,
Mark Gritter
markgritter

Subversion follies

We appear to have run into an odd situation at work, when using Subversion.

1. Create a new branch "initial"
2. Develop on "initial" branch, merging in changes from trunk once or twice.
3. svn copy "initial" branch to "feature" branch
4. Develop on "feature" branch, merging in changes from trunk occasionally.
5. Time to merge! Update "feature" from trunk and resolve all conflicts.
6. From trunk, svn merge "feature"

Step 6 should not produce any conflicts (other than tree conflicts) because we've resolved any actual discrepancies, and trunk hasn't changed since step 5. But what we get instead is that Subversion *first* applies all the change sets from the "initial" branch, and *then* applies all the change sets from "feature" after it was copied. That is, we see that it's applying rAAAA--rBBBB first, then rBBBB--rCCCC. But, the first step creates a *ton* of conflicts because trunk contains a lot of changes after rBBBB.

I am a little stumped as to why Subversion is behaving this way, or how to get it to do the "right" thing instead. We can certainly do

svn merge url-to-trunk@CCCC url-to-feature@CCCC .

to apply the differences between trunk and feature, but I think this is a less-desirable solution.
Tags: software, source control
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment