[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locking support
Re: Locking support
Fri, 31 Aug 2001 16:15:31 +0000 (UTC)
tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (SunOS/5.8 (sun4u))
Greg A. Woods <address@hidden> wrote:
> [ On , August 28, 2001 at 12:13:59 (-0700), Brian Clark wrote: ]
>> Subject: Re: Locking support
>> PooPoo. I've used CVS for years and have avoided that "insecure"
>> feeling some of us get from not knowing if we are working on a file
>> that someone else is working on. We've wrapped cvs edit in a perl
>> script that determines who else is editing the file and warns (OK
>> informs, if that makes you feel better) you who is editing the file.
> Talk about putting crutches on your crutches!
What crutches? What's wrong with knowing that someone is working on a file
before making the decision to work on it yourself? I am not advocating
locking, just warning. In our group we find it useful to have to opportunity
to confer with someone before making changes to a file they have decided to
change. This tends to be more important in OO languages then procedural
languages because there is usually a 1 to 1 relationship between files and
> (I was going to say "training wheels on your crutches", but that's just
> gives completely the wrong imagery! :-)
>> CVS has allot more to offer besides the "C" in its name:
>> -It's primary interface has remained command line.
> That's a pretty meaningless feature -- at least in any Unix-like world
> where pretty much anything of any value has, and always will have, a
> "command-line" interface.
Unfortunately, the Unix world is not the only world. My company is currently
trying to push GUI based PVSC on us. We are resisting with all the might we
>> -It supports directory structures (unlike rcs and sccs)
>> -It is free and open sourced.
>> -It has an extremely knowledgeable user base.
> You've not mentioned the one primary almost unique-to-CVS feature that
> seems to drag all kinds of people over and to suck them into using CVS
> even if it doesn't really meet their more important criteria (eg. even
> if they handle lots of non-mergable files and/or they are extremely
> opposed to concurrent editing for mergable files), and that's:
> -It has client/server support.
Agreed. That one is important.
>> I don't know of another version control system that meets all of these
>> criteria even close to as well.
> I'd say you've not looked very far (especially if you ignore as a
> requirement the client/server feature I added to your list). I've
> repeatedly mentioned several version control systems which VASTLY
> improve on CVS for many purposes and which have all the attributes you
> list, but which do not force concurrent editing in the way CVS does.
Thus the "I don't know of" qualifier. I write software for a living. I
don't evaluate version control software.
> In any case *ALL* of what you said is pretty pointless -- CVS was
> designed to *FORCE* you to get used to the idea of concurrent editing.
> That was the primary design goal: parallelisation of development! The
> other features are in part just gravy to make the concurrent editing
> easier to swallow. Building crutches around or into CVS so that you can
> pretend you're eating your broccoli while feeding it to the dog under
> the table is really kinda silly.
CVS was designed to...? Geez thats a strong argument (not!). Since when has
what something was designed for been a criteria for its use, especially this
long after it's initial inception. If the only people who used CVS where
those using it for what it was initially designed for, I venture to say you
would probably be it's only user ;-)
I've been using CVS for four years now. Prior to that, I used Source safe,
Clear Case, RCS, SCCS, A system from Rational whose name I can't remember
and various proprietary solutions built within the companies who've employed
me. The first project I used CVS for had no contingency for warning users
when they were about to work on files that others were working on. As I've
said, I always had an insecure feeling about this, and thus implemented
features in subsequent uses of CVS using watches that dealt with this. If
this use of CVS makes people uncomfortable, I'd suggest you attempt to get
these features removed.
One of the things I like about CVS is that it doesn't try to be a complete
source control package. It allows development groups to taylor it to there
needs and personal preferences.
Brian Clark -- Software Design/Development Consultant|
Pools of sorrow, waves of joy are drifting through my open mind, |
Possessing and caressing me. -- John Lennon, Across the Universe |
If your going to email a response to one of my posts, please also try
to post it if you can. I'd like to keep everyone involved!
RE: Locking support, Noel L Yap, 2001/08/22
- RE: Locking support, (continued)
- RE: Locking support, Ellison, Martin [IT], 2001/08/22
- Re: Locking support, Robert J. Clark, 2001/08/22
- RE: Locking support, Greg A. Woods, 2001/08/22
- Message not available
- Re: Locking support, Brian Clark, 2001/08/28
- module-tree, Wim Dausy, 2001/08/29
- Re: module-tree, Eric Siegerman, 2001/08/29
- Re: module-tree, Wim Dausy, 2001/08/31
- Re: module-tree, Derek R. Price, 2001/08/31
- Re: Locking support, Greg A. Woods, 2001/08/29
- Message not available
- Re: Locking support,
- Re: Locking support, Greg A. Woods, 2001/08/31
- Re: Locking support, Eric Siegerman, 2001/08/31
- Re: Locking support, Larry Jones, 2001/08/31
- Moving CVS Repository - Uncommited local changes, PRUDHVIDHAR lingala, 2001/08/31
- Re: Moving CVS Repository - Uncommited local changes, Matt Riechers, 2001/08/31
- Re: Moving CVS Repository - Uncommited local changes, Shyam L, 2001/08/31
- Re: Moving CVS Repository - Uncommited local changes, Larry Jones, 2001/08/31
- Re: Moving CVS Repository - Uncommited local changes, Greg A. Woods, 2001/08/31
- Merging changes from main line in to branch, PRUDHVIDHAR lingala, 2001/08/31