RE: multiple developers sharing one working directory

[Judy Pearson]

Noel -

Just wanted to clarify: we do have a Unix sys admin; the person we lost was a 
person who operated, among other things, as a source
control admin. So I am getting plunked into that space.

Thanks so much for all the info and input. I'll look into the advisory lock 
patch.

I don't consider your questions for the pro-locking crowd inflammatory at all, 
maybe because they sound a lot like the noise I make
and I know I'm always so reasonable :=) . You brought up some very good points. 
For now I'm focusing on making things work using
locking, but I'll incorporate your questions into any discussions I have with 
people and will certainly let you know how it goes.

- Judy

> -----Original Message-----
> From: Noel Yap [mailto:address@hidden
> Sent: Friday, June 07, 2002 5:19 PM
> To: Judy Pearson; address@hidden
> Subject: RE: multiple developers sharing one working directory
>
>
> --- 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
>