Exclusive checkout through SCC or CLI?

[deanaug]

The GUI client provides the option of checkout exclusive for items, to prevent multiple checkouts of files on the same branch. Do the SCC API or CLI client have this as an option as well? Looking at the CLI command, I don't see a -exclusive option or anything like that. For SCC, I don't have any info on the API that Plastic exposes for checkout operations.

We are considering doing all our EA work on a single branch, and if possible may want to configure EA / Plastic to enforce exclusive checkouts.

As a fallback, I should be able to add a before-clientcheckout trigger to disallow multiple checkouts on the same branch?

Thanks!

Dean

[miller]

HI Dean,

In branch-per-task or branch-per-developer scm pattern, you would rarely need checkout exclusive.

But here is the cli command:

cm co "filename" --exclusive

Miller

[deanaug]

Thank you for the help as ever Miller!

Note that the help shown for the co command from the CLI (at least for v187.22) doesn't show the --exclusive option, only -R and --symlink.

The only reason we're considering deviation from the branch-per-task for EA, is based on their documenation which recommends avoiding merge of XMI files. These XMI files are really just (text) XML files, so I'm not sure why branch/merge wouldn't work on them.

Does anyone out there have any experience with Plastic managed EA files, and branching considerations for them?

Thanks!!!

Dean

[psantosl]

Branching and merging on XML files works well since, as you mentioned, they're just text files.

There are specific files for XML merging in case you need something more advanced than just text-based compare tools. You could always plug one of Altova's XML tools: http://www.altova.com/diffdog/diff-merge-tool.html

The only "issue" with XML files is not about the files itself but about the following:

* Sometimes XML files are automatically generated by a development tool (Visual Studio 2003, for instance)

* Each time the file is re-generated it gets totally changed, not respecting the previous order of elements, making merge a hell, an unwanted and unneeded hell because if the tool were able to keep the order... the issue wouldn't happen.

* What we do with resx files (internally at Codice) is that we sort them before merging them, so we ensure we're not handling random changes made by the tool.

That's all folks!

pablo