Forced commit of merged items before I can do anything else?

[Wolfram]

Hiho.

New to PSCM.

I am having trouble with the concept of being forced to commit ALL merges, before I can do anything else (like committing other parts etc.).

In our work environment it regularly happens that we work on something, but have to merge stuff from other team members which is relevant to our work. However, we neither can nor want to commit our current state, as it is unfinished. Is that a concept that is no longer feasible/viable with PSCM, so we need to change our work process? If so, is that approach the branch-per-task concept, or are there other methods as well?

So is there some other way to get rid of these pending merge links? Or what is the best approach to handle a situation like this?

 

Thanks!

Wolfram

[psantosl]

Hi Wolfram,

I will try to make it clearer how merging works in Plastic.

You said:

Quote

 

I am having trouble with the concept of being forced to commit ALL merges, before I can do anything else (like committing other parts etc.).

 

 

Merge tracking happens on a changeset basis (commit basis) in Plastic, instead of on a file per file basis (like happened in old Perforce, Clearcase, even SVN and many others, but like what happens on Git, Mercurial and the DVCS generation).

What does it mean? Well, in the Branch Explorer you see the merge links going from changeset to changeset, and this is actually how things happens behind the scenes.

It means whether you merge the entire changeset or you don’t merge it.

Suppose you modified 5 files on a branch. You want to merge to main. You merge the 5 files or none. You can’t merge only 4, checkin, and later merge the one that was left. Why? Because the changeset is already marked as merged, there is no individual merge link on a file basis.

Why we do it this way?

Because very often teams find themselves merging branches with hundreds or thousands (or even hundreds of thousands, in some customers) of changes. Calculating the merge tracking for each file is linear: you can optimize it, but 100k files will take longer to calculate than 1, and at some point, it will be slow. But calculating based on the changeset history instead is super-fast. We know it well because we used to do merge tracking on a file per file basis, up to version 3.0. Then back in 2011 we released 4.x and we moved to changeset based merge tracking… and everything goes faster now. You pay a small price, though, you have to merge the entire changeset, but this is rarely a problem.

 

Let’s continue with your questions now:

Quote

 

In our work environment it regularly happens that we work on something, but have to merge stuff from other team members which are relevant to our work. However, we neither can nor want to commit our current state, as it is unfinished. Is that a concept that is no longer feasible/viable with PSCM, so we need to change our work process?

 

 

Ok, so you are working on branch main/task001 and then you want to merge from main/task101 for whatever reason, right? But you have pending changes in your workspace before merging, and you didn’t check them in, correct? Now you merge, and Plastic forces you to checkin *everything*.

Ok, we could certainly modify something here to make it easier but… we try to keep it consistent. What could we do? We could let you checkin *only* the files NOT involved in the merge. All the files involved in the merge must be checked-in together so we can correctly set the merge link between the changesets, that’s clear, isn’t it? As I said, we could modify this. We simply didn’t do it to avoid adding extra complexity to the code, that’s all.

 

As a rule of thumb: it would be easier if you checkin prior to merge, so your branch is clear and your previous status correctly recorded. Are you afraid of breaking the build? Then you should probably use “branch per task”, work on your own branch instead of main, and checkin very, very, often.

 

I’m not 100% sure I made it clearer to you, but I think I gave you the background to better understand how Plastic works and how you can take advantage of it.

 

I know it is slightly different from what you are used to, but trust me, it won’t take long to get used and get the best out of it.

 

Thanks,

 

pablo

[Wolfram]

Hi pablo!

 

Thanks for the detailed explanations!

Yeah, guess we need to move over to the very different paradigm of "commit everything, anytime, even if it doesn't even compile - just not on the mainline", instead of the old, serial "only commit when you completed all the work, merged other mainline changes, tested stuff, and everything is finished".

But it seems to make a lot of sense.

And if you consistently do a "commit in your branch before attempting a merge", there is no longer a problem of wanting to do partial commits of merge results.

[manu]

Hi Wolfram!

If you have more questions don't hesitate to contact us!