How do I prevent this...

[Xorcist]

We just started a project. All of us started with the same base repository. One user created a branch, merged, created another branch off the merge point, merged, created another branch off that new merge point, and merged. another user created a branch and did not merged. I was tasked with generating a build. So I needed to get everyone's changes.

 

I grabbed branch from the user who had not merged, and everything went fine. The branch came in attached to the proper main changeset and all looks good. But for the other user since the changesets did not exists for various branches due to the multiple branch/merges he did. I ended up having to pull his main branch and got this:

 

 

I wanted to roll this back but I can't delete any of his (purple) changesets. It's telling me a branch, label, or changeset it linked to the last node.

 

What is the proper work process to prevent this from happening? I don't want to be pulling the entire main branch from everyone. I really want just their branches. Am I going to have to have them to individual tasks, then I can pull and merge, and them have them re-pull my main to keep all the branches nicely separated and clean. We had this same issue in a previous project and just ended up having everyone pull everyone else's main branch every time they did an update. Needless to say, it was a large mess of branches within the main branch. I mean is this expected? Because I was expecting to have standalone branches for each and every task.

 

 

Edit: Not sure if this is the proper solution, it after pulling his main branch, I was then able to pull all of his other branches (and they now link to the main branch properly and are separated from it). I was then able to rollback by deleting the chain of changesets in order and through association. Without the other branches this was impossible though. Is there any option to have all the branches pulled when the main branch is pulled?

[calbzam]

Hi,

 

- We always recommend branch per task methodology:  http://www.plasticscm.com/infocenter/technical-articles/kb-branch-per-task-workflow.aspx    The developer works in a task branch, once he finishes, he pushes the changes to repository, and then you can integrate the branch in your main branch.

 

- We also recommend to have an "integrator":  The developers only perform commits in task branchs and never in main branch. The integrator perform the merges. This way main branch is always pristine.

What is meant by integration? Once a number of tasks are finished, it's time to create a new release. Remember that "release early, release often" is a best practice worth following to avoid big bang integration (the root of all evil in the SCM world).

Who uses it? The integrators. Integrators can be developers playing the role once a week or once a day (depending on the release creation frequency). The integrator role can be a full-time job on big projects. Integrators not only merge the branches back to main, but are responsible of getting the build done right. They'll take a quick look at the code and they'll ask the developers for more information if something in the code is not clear, or if conflicts arise. Responsibility is key to the role of the integrator.

 

- It´s also very interesting in your scenerio to set up a SYNC VIEW: ( http://codicesoftware.blogspot.com/2011/06/distributed-synchronization-view.html )    It´s the best way to control all the incoming and outogoing changes.

 

Regards,

Carlos