Exclusive checkout

[mauro.assis]

It

[miller]

mauro, absolutely not!

why do you need a true parallel development SCM system to work with exclusive checkouts? could be great if you share your thoughts with us.

cheers,

miller

[mauro.assis]

I was affraid that my message could break your harts ...

The answer is: I

[mauro.assis]

I was affraid that my message could break your harts ...

The answer is: I

[mauro.assis]

Hi guys, I shared my thoughts with you, what do you think about that?

[Guest]

Hi, Mauro:

First, excuse me for not answering before.

Regarding your question, we have the same problem: we also have documentation repositories (you know: we don't only write code but also write documentation! :-))) with .doc, .vsd, images and so on, and merging is not an easy task, since those files are binaries and Plastic SCM only allows you to keep source, destination or base, but not merging them actually. Merging binary files as text files do is not doable.

So in this scenario branching is a good practice if you know that you and only you will work in a certain bunch of files, otherwise it will make no good.

Your best option is to use the exclusive checkout (available from both GUI and CLI). Unfortunately, this is not the default option, because Plastic SCM is intended to be used in parallel development, which is not in your case, indeed.

Another important piece of advice here (from my own experience) is to update whenever you're about to work in some files; this is always important, but even more in your case; because if you work on binary files and then try to checkin and a merge is needed because your workspace wasn't updated, you'll have to decide if you want to lose your work done or others' (or open both revisions and merge them manually)!!.

Sorry for the inconveniences and best regards,

Luis

[deanaug]

Hi Luis (and company!),

I have a question about your statement "So in this scenario branching is a good practice...".

If you have, say, a Word document that is on one branch, and you create a child branch and make changes on it, how do you "promote" that binary file to the parent branch without doing a merge? The only thing I can think of is to check out the file on the parent branch and *replace* it with the version on the child branch, rather than do a merge as you would do with text files in this scenario.

As you said, we write gobs of documents, and currently everyone is sharing a branch for all updates. (BTW we have learned the hard way the lesson of making sure to update before checking out!)

To avoid the problem of forgetting to update before checking out on shared branches, I'm considering adding a before-clientcheckout trigger that will do an update of the items about to be checked out, to make sure the user is checking out the latest version. I've already advised the group to use exclusive checkout (for now), so if they are doing that the "auto-update" prior to checkout should always get the correct latest version. Any negatives or alternatives to doing this?

Thanks!!

Dean

[psantosl]

> If you have, say, a Word document that is on one branch,

> and you create a child branch and make changes on it,

> how do you "promote" that binary file to the parent branch

> without doing a merge?

Why you don't want to merge??

If the file is binary, Plastic (in case of conflict) will let you choose between the two contributors, so, it will save you the work of having to do it manually checking out in the parent and replacing. Merge will do it for you and keep traceability. So, simply best.

In case of WORD files: you can configure Word as merge tool to do "three way merges"... so, as good as with text files.

> As you said, we write gobs of documents, and

> currently everyone is sharing a branch for all updates.

> (BTW we have learned the hard way the lesson of making

> sure to update before checking out!)

Yes, to avoid unneede merges!!

> To avoid the problem of forgetting to update before

> checking out on shared branches, I'm considering

> adding a before-clientcheckout trigger that will do

> an update of the items about to be checked out,

> to make sure the user is checking out the latest version.

> I've already advised the group to use exclusive checkout

> (for now), so if they are doing that the "auto-update"

> prior to checkout should always get the correct latest

> version. Any negatives or alternatives to doing this?

I think this is an excellent alternative. A small trigger that will only execute on specific file extensions (for instance, so it won't impact overall performance) and will make sure you're on LAST or at least warn you if you aren't... I think it is the best possible choice.

For 4.0 I'm considering whether we should have some sort of "built-in" option to support this scenario.

I'm thinking on some sort of "server side" list of "files that need to be ON LAST before CHECK OUT", so the system will deny the checkout if you're not on LAST...

But, after sending a few alternatives to some of the engineers here... I feel it is just an overkill and while it could save some work... a trigger sounds like the right place... without a customized solution that will always lack some details...

Of course, what would help users is to provide this trigger somehow, so you don't have to come up with it yourself...

Or at least have some generous user like you sharing it with the world on the forum... and winning some Plastic kuddos!