Thanks Brett. My newfound interest in the SCM API derives from the addition of the scm-provider for Wagon. I am really excited about this concept, and looking forward to contributing.
I think the issue is definitely one of terminology. There are effectively 2 types of "checkout". Reserved and unreserved. By default, CVS and Subversion use unreserved, while Clearcase and MKS use reserved checkouts. In general, it's possible to make any of these tools behave however we want. 3 options: (1) decide on reserved vs. unreserved and stick with it, (2) create separate commands, or (3) add a boolean to the existing checkout command. With regards to "sandboxes", I think there needs to be a peer to the ScmRepository: ScmSandbox. The ScmSandbox would be responsible for mainting the linkage between the local filesystem and the remote repository. Instead of providing the ScmRepository as an argument to the ScmCommands, you would provide the ScmSandbox. This also addresses the current need to constantly call ScmFileSet.getBaseDirectory(). FileSets would always be relative to the Sandbox.... - Mike ultimate solution is to modify the ScmRepository API. At the time that an Repository is created, it should be tied to a directory on the local filesystem. This takes care of the more complicated systems like ClearCase and MKS where the tool needs a linkage between the local FS and the remote repo. On Thu, 12 May 2005 23:56:06 +1000, "Brett Porter" <[EMAIL PROTECTED]> said: > (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 > > > > > > > > >
