Larry, > No, but the whole point of CVS is to allow concurrent development in > separate sandboxes. Sharing a sandbox is rarely a good idea since you > just end up stepping on each others' toes.
1. if CVS is only supposed to allow distributed unreserved - why does it allow personb to commit persona's sandbox? Surely that's a bug. Certainly putting 'persona' as the author when personb committed it defeats part of the value of versioning (unless you change the definition of 'author')? (a/b) 2. if CVS is not the best tool for a shared sandbox with unreserved versioning - what is? One that isn't rubbish, and preferably one that is regularly updated/improved by the vendor based on customer wishes or alternatively one that is open source allowing customers to improve it. 3. if CVS is the best tool - why not accept that and allow it to be extended to better let people get the most out of it? I think tools are there to help me get my job done, and support me how I work. Tools that force their methodology (unnecessarily) on me are generally no help. Your POV is a valid one (and not even uncommon). Tools that are limited to particular narrow methodologies are often very popular - eg: the iPhone. I'm very tempted to 'switch sides' here and agree with your argument... The iPhone is popular because a narrow/clear methodology is generally easier to use with little training - anything you "shouldn't" do doesn't work. But here the 'argument' gets messy. Whilst many other tools are available - ones that support genuine reserved workflows, or shared sandbox workflows are 'mostly' not open source, and are mostly rubbish (combersome, not client/server, restricted to particular O/S's, haven't been updated in years etc). So in the absence of any alternative, and me being mostly a lazy sod and not wanting to write something from scratch, and me thinking that CVS gets me 80% of the way there - 'I' think/thought the right course is to 'extend' CVS with some (very minor) patches to better suit my workflow (that's the 'real' value of 'free software' for me - the freedom to change it, nothing to do with price). Tony Hoyle and everyone else involved in the project were very surprised when LOTS of people also thought this was a good idea, and began downloading 'CVSNT' in droves and requesting other 'minor' changes that they explained would have a significant beneficial effects on their workflow. I wont list them all for fear of sounding like an advert. So my challenge to you is this: Rather than say "do this" or "don't do that" - can you convince the person as to the value of changing their behaviour? If you do 'this' instead you will see 'this' enormous benefit. If they agree with you (that it will be more valuable/helpful for them to work the other way) - I'll happily agree with your position. If they don't agree with you - I'll say the best course is to adapt the software to work they way they want to work. Regards, Arthur A) for shared sandboxes CVSNT has 'cvs edit -A' which sets an O/S ACL on the file so now only the person who 'edited' the file can commit it B) as mentioned in the previous post, CVSNT creates CVSROOT (CVS/Root) strings without the username by default, so the author name comes from the user who commits not the user who created the sandbox. This behaviour is frequently overridden by poorly written GUI's - but that's another topic. P.S. Is this getting seriously off-topic? I'm happy to continue the conversation privately or publicly.
