Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are doing a major refactor of the layout of our source tree. Masses of files are being moved, folders are being renamed, etc. etc. We currently have everything in SVN.

We're going to move to either GIT or HG in the future.

However, now we're thinking that maybe we should move to GIT or HG first and then do the refactor. We're worried that work in progress on svn branches aren't going to be able to merge the refactoring changes into their branch NOR are they going to be able to merge any changes to files that have been moved and/or renamed back into the trunk.

  1. Which between GIT and HG would better handle this type of refactoring?
  2. If we do move to GIT/HG and then do the refactor, what will be merging be like for the work in progress branches once they move to GIT/HG?
share|improve this question
1  
Go for it, switch to Mercurial/Git before you start to refactor! –  Oben Sonne Aug 22 '11 at 21:01
add comment

migrated from stackoverflow.com Aug 22 '11 at 19:39

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 6 down vote accepted

Mercurial knows about renames (and moved files) and will do the right thing when merging.

We start with two files, a and b at the root of the repository. Then:

$ hg mv a aa
$ mkdir bb
$ hg mv b bb/b
$ hg ci -m "rename a and move b"

Now let's change the files before the moves:

$ hg up -q 0
$ echo a >> a
$ echo b >> b
$ hg ci -m "change to original files"
created new head
$ hg glog
@  2:311bf19d4ce3  - change to original files (2 seconds ago)
|
| o  1:b72cbd89ae3d  - rename a and move b (17 seconds ago)
|/
o  0:4d276a78eee7  - . (3 minutes ago)

And now merge with the changes:

$ hg up 1
$ hg merge 2
merging aa and a to aa
merging bb/b and b to bb/b
0 files updated, 2 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Mercurial sees the changes even though the original files are no longer there:

$ hg diff --nodates
diff -r b72cbd89ae3d aa
--- a/aa
+++ b/aa
@@ -0,0 +1,1 @@
+a
diff -r b72cbd89ae3d bb/b
--- a/bb/b
+++ b/bb/b
@@ -0,0 +1,1 @@
+b

I'm pretty sure git behaves similarly in this situation.

As for choosing between the two, that's a different question ;).

share|improve this answer
1  
+1 I agree in that the OP's use case does not help in deciding if to choose Mercurial or Git -- both support it quite well. –  Oben Sonne Aug 22 '11 at 20:59
add comment

Yes, you must migrate to DCVS-of-choice before refactoring, merging refactored in SVN is big headache

  1. For ordinary refactoring (only move in commit) both Git and Mercurial are at the same level of usability ("very good") They differ in situations, then you'll move part of code between files in refactoring, because GIT uses auto-guessing on renames with some heuristic, Mercurial, in contrast, expect user's intervention and flagging renames explicitly (but Mercurial also uses "similarity level" for guessing pair under the hood)
share|improve this answer
    
I've done big refactorings of Java and C++ code in SVN without problems. Really, when refactoring a codebase, VCS is the least of your problems. Just do things in steps, check in frequently, and you'll be fine. –  quant_dev Sep 18 '11 at 19:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.