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:[EMAIL PROTECTED]] > Sent: Friday, June 07, 2002 5:19 PM > To: Judy Pearson; [EMAIL PROTECTED] > Subject: RE: multiple developers sharing one working directory > > > --- Judy Pearson <[EMAIL PROTECTED]> > 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 > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
