RE: multiple developers sharing one working directory

[Noel Yap]

--- Judy Pearson <address@hidden>
wrote:
> > 1. Why did the group move from VSS to CVS?
> 
> The group has been wanting to move from VSS for
> quite awhile. I can think of:
> 
> - We're a Unix shop and want reliable,
> smoothly-automated regular (nightly or more often)
> and easily configurable builds on our Unix
> boxes. Couldn't see a nice way of arriving there
> using Windows VSS. We looked into Unix VSS for a
> short time (bad idea: buggy and
> unsupported).

It's not a good sign if your company is a Unix shop
and they don't have a proper sysadmin.

> - Doggy off-site access (I don't have the details -
> I only know it was tooooo slow).

I can imagine since Windows is so GUI-centric.

> - There were various other complaints about VSS
> behavior. It was a pain to override working folders
> set below the current project
> level. There were timing problems with transferring
> files from the Windows side to Unix via Samba
> resulting in end sections of files
> getting dumped. People wanted Unix command-line
> access to the repository. I don't remember the rest.
> 
> We're moving to CVS primarily because we want
> something mainstream and Unix-based that is not very
> expensive.

Which rules ClearCase out :-)

> > 2. Why does the group not like CVS?
> >
> The group as a whole is quite mixed in their
> attitudes about CVS. A number of people are quite
> relieved to be moving to a standard,
> Unix-based repository system. For most, switching
> from the repository-based VSS to the workspace-based
> CVS is a mind-bender.

This is understandable.

> Some of
> the developers have only used VSS and they've used
> it for over 3 years. While they were annoyed with
> VSS, they expect standard
> Windows apps behavior and don't think they're
> getting it from WinCVS. Two of the people in the
> small group that is doing this jsp
> work are very Windows-centric and, I think, don't
> like anything that smells of Unix. Unfortunately,
> these are the first people to be
> jumping in with both feet.

I've never used WinCVS so I can't comment much about
this.  Have you tried using any of the other GUI front
ends (none of which I've myself tried) out there? 
Maybe one of them'll make these two a little happier.

In the end, they'll either have to bite the bullet or
find a shop that'll make them happier.

> Another thing that muddies it all: After a lot of
> wrangling, our boss decided we would use CVS with
> locking (I offered to wrestle
> him over it, but he just pulled rank on me). We're
> using our own tcl macros in WinCVS to do locking and
> editing - and the reverse -
> in one-step processes. I am sure some of the
> confusion people are having stems from the square
> peg, round hole problems associated
> with using locking in cvs. In addition, there were
> other GUIs that I think would have been better
> accepted than WinCVS, but got
> ruled out a priori because they didn't support
> locking and didn't have decent macro tie-ins to
> compensate.

You might want to look at the advisory lock patch
available at SourceForge under project RCVS (I really
need to write a FAQ about this).  This patch adds the
"-c" option to "cvs edit" and "cvs ci" such that "cvs
edit -c" will abort if another edit exists and "cvs ci
-c" will abort if no valid edit exists (you might also
want to take a look at the other patches for "cvs
edit" like the multiple edits patch).

Advisory locks aren't exactly reserved locks since:
1. Users don't have to use the options (although
putting them in their ~/.cvsrc files will help.
2. Users can override the options with "-f".

OTOH, they'll provide more protection than anything a
front end will give:
1. You won't have to answer the following:
   a. If someone uses the command line or another
front end to subvert the reserved lock, what'll
happen?
   b. How will the system recover?
   c. Will the system give meaningful errors?
   d. Will the system overwrite what's been checked
in?
   e. Will the system even know about it?
   f. What happens to the working directory of the
user who subverted the reserved lock?
2. It's more integrated to the product.
3. Adoption by the standard release is in the works
(although I don't know how far along this is).

> Maybe that's more than you wanted to know.

It's as much as I needed to know to help point you to
other options.

So, some more questions (really for your boss or
anynoe else who favors reserved locking):
1. Do you agree that traditional reserved locking
version control systems have a bias towards the first
person to do a checkout?
2. Do you think the work being done by the first
person to checkout is any more special than the work
being done by the ones after him?  For example, is it
more important or easier to code?  Or do you think
being first to check out is just a circumstance and
should have no bearing on the decision on who gets
priority?
3. Assuming users don't do willy nilly checkins and
only checkin stuff worth checking in, do you think the
first person to checkin is further along in their work
than the others and should therefore get preference?
4. Can you think of reasons NOT to place bias towards
the first person to checkin?
5. Are you aware that the most common problem in
traditional reserved locking systems is users
subverting the locking mechanism by modifying copies
of the files they need?  IOW, they do concurrent
development outside of the tool's realm.  Makefiles
and configuration files are a common place to do this
since they are generally touched by many people.
6. If developers are going to do concurrent
development anyway, would it be better if the version
control tool supported it?

Using advisory locks gives control up front since
users are notified upon checkout while allowing
concurrent development since users aren't tied by any
restrictions.  I think using advisory locks is a good
blend of the traditional reserved locks and the "new
fangled" concurrent development and would be good for
any shop that is afraid to go cliff diving but
wouldn't mind wading in the waters.

I don't mean the above to be inflammatory (I know
email isn't the best medium to get intentions across).
 If you do ask your company these questions, please
let me know how it goes.

HTH,
Noel



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com