Using git/mercurial on projects with continuous refactoring?

Question

I am trying to understand if I really have any case for using git/mercurial.

The projects I work are java and c# projects, usually with 5-20 people working towards a com

Answer 1

In terms of mentality, there is sometimes a benefit in being able to create a soft-branch, perform all the changes in the soft branch, test the result of the changes in the soft branch, and then when the soft-branch is "complete", reintegrate it with the main branch locally, retest it, and then propagate it.

This in some cases is better than the rushed head, because you don't have the constant interruption of the existence of others debug code fouling up your code to add non-errors to handle.

It also means you can commit more often, giving a more comprehensive history, because commits don't instantly turn up everywhere creating problems.

Also, when reconciling the soft-branch with the shared mainline, you get to see a nice complete change-set, showing you both all your collective changes, and all their collective changes, which opens the door for nice code review opportunities.

Additionally, from a testing perspective, if you have more soft-branches, you can run the tests on the soft branches before merging them back into the main branch, and have a standard by which, a branch does not get merged back into the main branch until it has

1. Passed Tests on its own
2. Passed Tests after main branches changes have been reconciled into the soft-branch

Thus giving you an extra guarantee of code quality, in that your main collaboration branch is extra squeaky clean, because failing code is not permitted to appear on it.

( Which also limits the problem solving domain, because you only have to test your own changes for the most part, and when you are 'done', only then do you have to worry about what everyone else has done, and what they have done should also be passing tests, which means when something does fail, you only have to look at what you did to solve the problem )

But would I continiously update from central repo head into my softbranch ? This is really the essence of my problem

The beauty of the branch system is you can pull "whatever's been deemed stable by others" into your local copy as needed.

"Continuous Update" becomes unnecessary, because you don't have the same problems manifesting.

a  b   center
         |
         |
         /      Key:   / - | \   = Flow
/----<---|             < >       = Flow Directions
|  /--<--/             *         = Commit 
*  |     |             T         = Test
|  *     |             M         = Merging with "Current" state of common branch
*  |     |             C         = Tests Complete and Current state is "sane"
|  *     |
T  |     |
|  T     |
|  C     |
|  |/-<--/
*  M     |
|  T     |
*  C     |
|  \--->-\
*  /---<-/
T  |     |
C  *     |
|/-----<-/
M  |     |
T  *     |
|  T     |
*  C     |
|  |/-<--/
*  M     |
T  T     |
C  \-->--\
|/---<---/
M        |
T        |
C        |
\---->---\
         |

Also, because of how the system works, later on, this could also occur:

a  b   center
|  |     |
T  |     |
C  *     |
|/-----\
         |

The entire concept of their being a "head" in such a scenario vanishes. It there are dozens of heads, which one you see is prone to perspective.

I might also add, that these logical branches, although displayed as separate here, can quite feasibly represent either seperate checkout locations, or mere different soft branches on a singular machine. a & b could in fact be a single developer.

In essence, "Continuously updating my softbranch from mainbranch", is conceptually meaningless. Because in fact, there will be changes not represented in mainbranch yet, and when will you know that they have been pushed or not? SVN Gives you this false illusion of a "singular" code state, when in reality, the instant one user opens a file in their text editor, they have in fact created a very short life soft-branch, a change, that is occurring,that nobody knows about, and for this illusion to be sustained the way you think it works, in effect, the user has to commit after every character, which is hardly practical. So in reality, people get used to the fact that different locations get "out-of-sync" with each other, and learn ways to solve it so it's no longer a problem.

Also, the "constantly updating my tree with everyone elses changes" has a core problem, in that, you have far too many distractions, you are constantly being bombarded with everything everyone else is doing, and if they're making a series of 1 line commits to test something they cant test on their own machine, then you have a nightmare with the ever changing file, and the users seeing the seemingly random changes cant make sense of them.

By permitting longer runs between commits, and then seeing the net result in batches and seeing only the net result of your peers changes all at once, you can see immediately what code has been changed since you checked out and a cohesive overview of what it means for your code, so you can just write your own code and get it over with.

If you have any doubts

Start off with something simple and don't transition cold turkey, some of the concepts in DSCMs can be a bit daunting ( I've seen tragic failure by many to understand the concept of vertically stacked soft-branches ) , move a small non-essential part of the codebase to Git/Mercurial and play with it for a while, experiment with the benefits and what it can do. There's no better proof than experiencing it yourself, and all my lovely explanations are unlikely to communicate what you need to understand and can only be learned by trying it, and failing a few times ( because failure is a key part of learning )