Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Rename support on merge

Friday, August 27, 2010 Pablo Santos 0 Comments

I'm going to go back to the basics today and describe how Plastic handles renames during merge with two different cases:
  • Rename a file, modify it in parallel in a second branch and check how the two branches are correctly merged back, which means: the result file is renamed and it contains the changes from the two branches.
  • Divergent merging: what if we rename a file in one branch and also in a second one to a different name and we merge back?

    As simple as it might sound, renaming during merging is one of the points where most of the SCMs break... And the good news is that Plastic simply excels there.

    Handling renames during merge

    The scenario is very simple:
  • Create branch task003, rename and modify file agent.cs there
  • Create branch task004 (in parallel with task003) and modify agent.cs there
  • Merge back both branches to main
    The expected result is: getting agent.cs renamed and including the changes from the two branches.

    This is what Plastic does, but systems like Subversion dramatically fail: SVN will create two files as result and won't directly merge the changes...

    The following screencast shows Plastic in action dealing with this example:

    Divergent renaming

    The scenario is the following:
  • Rename a file on a branch
  • Rename the file to a different name, in parallel, on a different branch
  • Merge the branches together

    Plastic is able to detect the double rename and come up with a solution: choose one of the names or propose a new one. But Plastic won't end up creating two files and leaving you alone to handle further merging (changes on the files) yourself.

    Interestingly this is exactly what Mercurial does: it will create two files with the two names and warn you to solve the situation somehow.

    Check it in action here:

    Pablo Santos
    I'm the CTO and Founder at Códice.
    I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
    I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
    I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
    And I love simple code. You can reach me at @psluaces.
  • 0 comentarios: