RE: history shows different login -CVS

[Arthur Barrett]

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.