(CC'ing some more folks - hope you don't mind) Mike, this is great news - it'd be great to include your work.
I don't have experience with Clearcase or MKS, but remember from using other systems about locking revisions. It seems to me that checkout, in our API, is more like creating a sandbox, and what you want is a way to get an edit lock on a while (which sets it writable), and release it again. CVS actually has this capability too (though I don't know if it takes an exclusive lock or not - I think it just notifies you if someone else does the same thing). We're definitely up for refactoring the API if it doesn't make sense in all situations (hence the reason it is in alpha - the code itself works quite well besides that). So far, the API is mostly being used for read only operations (other than tagging and the occasional commit). If you'd like to subscribe here ([EMAIL PROTECTED]), it is very low traffic and we can work through it. Thanks again for contacting us. Cheers, Brett Mike Esler wrote: >Hi Brett. I've started working on an MKS provider for the maven scm api >that I plan to contribute back. > >I have one question regarding the API, specifically the semantics of the >checkout command. Basically, the checkout command has very different >meaning for different version control systems. In CVS and Subversion, >checkout basically creates a new sandbox. With a tool like Clearcase or >MKS, you have to create a "VOB" or "Sandbox" before you can do a >checkout. This step seems to be missing from the Maven SCM command set. >Is it assumed? If so, then the "checkout" should be a no-op for >Subversion and CVS since the tools assume optimistic concurrency and >make everything read-write by default. There's no notion of "locking" in >those tools. For Clearcase and MKS, checkout will lock the file. > >This creates an issue related to checkin. MKS requires me to obtain a >lock (via checkout) before I can checkin. > >One way to rectify this is to create a new Maven SCM command >"createsandbox". Interested to hear your thoughts on how to handle >pessimistic concurrency version control tools. > >- Mike Esler > > > >
