cvs
Win32 M$
>In my oppinion locking is a mandantory requirement for any good version
>control tool. E.g. if there is a strict requirement from the project /
>quality management to use locking for development, period ! So I have to
>use
>locking or I have to use another version control tool.
Management should not force the development to use the tool in the wrong
way. CVS is not the management tool - if you have to deal with this kind of
management I can only tell you one thing: Run, run away as soon and as far
as you can! ;)
Even thought Ver. Cntrl. tools need locks, it doesn't mean that it is
mandatory to use them all the time. If the tool is smart enought to handle
the parallel development (CVS is) why do you want to dumb it down to the
strick locking?
>I'm currently trying to persuade my colleagues that CVS is a good version
>control tool for our company. The current mechanism with 'cvs admin -l/u'
>is the absolute minimum. A GUI can hide this inconvenience from the user.
>But if locking wouldn't be supported, we definitly have to choose another
>system.
Try to persuade your colleagues that CVS is a good version control tool
BECAUSE IT DOESN"T NEED LOCKING! Truly, it hurts me when people try to use
locks just because they feel more 'safe' that way. But when they first time
experience that it actually works WITHOUT locking, and it does the right
things (most of the time) they don't want to hear about locks any more, and
would kill if somebody starts to lock files again!
BR,
Jerzy
The first thing they don't teach you at school: "Never say never".
All the issues not related to the list please send to me in private, thanks.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Win32 M$
Win32 M$
>The usual meaning of "reserved locks" is that the tool tries its best to
>prevent
>multiple people from modifying the file. None of the CVS solutions do
>this.
Not realy - even with the reserved locks you can still modify the file, but
you can not 'commit' your modifications to spoil others job.
>All the CVS solutions rely on developers adhering to a process that the
>enitre
>team agrees to.
Same applies for the reserved locks.
>CVS should never be able to have "reserved locks" in the above sense.
Did you read the manual? It says something different... With all do respect,
you lost yourself in what YOU need from tool and what YOU think tool should
work like. However, there are other peoples too in this world and they need
different things. Some of them need locks. So simple...
>If it
>does, all people will do is work around the mechanisms. For example, in
>RCS, if
>I find I can't lock a file, all I have to do is chmod the file, work on it,
>then
>later on, do my best to manually merge in others' changes.
Backdoor, it is out of tool scope so it is out of discussion.
>An alternative is to
>work on a branch and merge in the changes later on. The major difference
>between CVS and other tools is that parallel development in CVS occurs in
>working directories (which can be considered virtual task branches) whereas
>in
>other tools, a physical branch must exist.
Not really. You will find that often you are working in your 'working
directory' with the other tools too.
>CVS's features already make it easy for developers to communicate and merge
>--
>there's no need for strict locking. Can you give me an example where
>strict
>locking is necessary and communication doesn't suffice?
It happens every day just because people are people and they do not always
feel like communicating ;) So, you need some support in the rare cases when
it is critical. Sometime it is, so lets just consider the reality:
1. There are locks in the CVS.
2. These locks are not nice.
3. These locks are not perfect too.
4. It is better to not use the locks with CVS.
5. But if you feel you need them, see p. 1.
Examples (briefly, don't like to repeat the same thing):
1. Nasty programming environment, when the files are modified in the way
difficult to merge (like VB or some modeling tools or automartically
generating code wizard etc.).
2. Migration from other Ver.Cntrl. to CVS (keep things in sync).
Tobias Weingartner
>
> Did you read the manual? It says something different... With all do respect,
> you lost yourself in what YOU need from tool and what YOU think tool should
> work like. However, there are other peoples too in this world and they need
> different things. Some of them need locks. So simple...
Please point me to chapter and verse about reserved "locked" checkouts
in CVS. I'd like to know where in the documentation this is present.
--Toby.
Win32 M$
>Please point me to chapter and verse about reserved "locked" checkouts
>in CVS. I'd like to know where in the documentation this is present.
It is present in few places, but the meaningful is the text in the 'Multiple
developers' section, where you can find the note that reserved checkouts (or
file locking, "reserved locked checkouts" is too much of a butter in a
butter - reserved are locked). If you read it carefully, you will find that
it does not implement it nice, and also that is doesn't do so YET. BTW: Why
don't you just use the find option of your browser and look it up yourself?
You can also find things in the change log in the CVS source code.
I do not suggest to use locks all the time, but it is there, it works, and
you might need it...
Also, it is worth to note that even the tools which supposed to be used with
locks quite often have the 'concurent' model as an option. Both models
(Concurent and 'locked') have it's good and bad sides, and it all depends
what you doing.
The right tool for the right job.
BR,
Jerzy
Ps. Sorry for my multiple post - problems with browser :(
Tobias Weingartner
>
> developers' section, where you can find the note that reserved checkouts (or
> file locking, "reserved locked checkouts" is too much of a butter in a
> butter - reserved are locked). If you read it carefully, you will find that
> it does not implement it nice, and also that is doesn't do so YET. BTW: Why
> don't you just use the find option of your browser and look it up yourself?
> You can also find things in the change log in the CVS source code.
I wanted you to do it, because I wished to have a rather extensive list of
places that talk about this reserved checkout feature that CVS supposedly
supports. Now, let's have a look at the documentation. For reference, I
am using cvs-1.10.8, and the documentation found in its 'doc' directory.
First, we'll have a look at 'cvs.ps' ("Version Management with CVS"). Please
look on page 61, under the heading "Multiple Developers". Here it says:
"...One solution, know as file locking or reserved checkouts, is to allow
only one person to edit each file at a time. This is the only solution
with some version control systems, including RCS and SCCS. Currently the
usual way to get reserved checkouts with CVS is the 'cvs admin -l' command
(see Section A.6.1 [admin options], page 91). This is not as nicely
integrated into CVS as the watch features, described below, but it seems
that most people with a need for reserved checkouts find it adequate."
Then on page 91, we find the following:
"...This is the CVS interface to assorted administrative facilities. Some
of them have questionable usefulness for CVS but exist for historical
purposes. Some of the questionable options are likely to disappear in the
future. This command does work recursively, so extreme care should be used."
Then, on page 92, about 'admin -l' we find:
"...This can be used in conjunction with the 'rcslock.pl' script in the
'contrib' dirctory of the CVS source distribution to provide reserved
checkouts ... See the comments in that file for details (and see the
'README' file in that directory for disclaimers about the unsupported
nature of contrib)."
Then, looking in 'rcslock.pl' in the contrib directory, we find:
"...Author: John Rouillard... Supported: Yeah right. (Well what do you
expect for 2 hours work?)..."
Then, reading 'README' in the same directory, we find:
"...But, we must point out that these contributions are really, REALLY
UNSUPPORTED. In fact, we probably don't even know what some of them
really do ... [this] also means that no one has volunteered to accept
and check in changes to this directory. So submissions for new scripts
to add here are unlikely to be accepted. Suggested changes to the
existing scripts here conceivably might, but that isn't clear either,
unless of course they come from the original author of the script."
So, to sum up. Yes, CVS can do reserved checkouts, but it is wholy, and
totaly unsupported. It may go away completely in the future (I can already
hear people scream...), it may change in non-compatible ways, etc. In
basic, if you are going to do reserved checkout, YOU ARE ON YOUR OWN.
This is how I interpret the above, YMMV...
> I do not suggest to use locks all the time, but it is there, it works, and
> you might need it...
I did not suggest that you did. I mearly wished to have a nice detailed
analysis of the current documentation of "locking/reserverd checkout"
support within CVS.
> Also, it is worth to note that even the tools which supposed to be used with
> locks quite often have the 'concurent' model as an option. Both models
> (Concurent and 'locked') have it's good and bad sides, and it all depends
> what you doing.
Very true. However, most tools also have one or the other side that they
do better. CVS does the non-locking stuff better than the reserved/locking
stuff. At least my experience has taught me that...
> The right tool for the right job.
In this case, I'd say that if your *WHOLE* development model depended on
reserved checkouts, then CVS is not your tool of choice. If you have a
couple files, then maybe CVS could be hacked up to do a decent job about
40% of the time, with absolutely no guarrantee that future versions will
continue with this support...
--Toby.
Tobias Weingartner | Unix Guru, Admin, Systems-Dude
Apt B 7707-110 St. | http://www.tepid.org/~weingart/
Edmonton, AB |-------------------------------------------------
Canada, T6G 1G3 | %SYSTEM-F-ANARCHISM, The OS has been overthrown
Win32 M$
>>Why
> > don't you just use the find option of your browser and look it up
>yourself?
> > You can also find things in the change log in the CVS source code.
>
>I wanted you to do it, because I wished to have a rather extensive list of
>places that talk about this reserved checkout feature that CVS supposedly
>supports.
At first I thought it is a trap. But now I can see it is lazisness ;)
>So, to sum up. Yes, CVS can do reserved checkouts, but it is wholy, and
>totaly unsupported.
What a NEWS?! UNSUPPORTED? REALLY? Man, I will better stop using it right
NOW! Locks have no future? Oh dear, what do we do then? Stop using CVS? That
is an option. I will not cry, nor scream. Nobody in my team will. They will
be happy to move back to Source Safe (or SourceOffSite - the future
replacement for CVS (perhaps) since SourceGear aquired CVS).
Now, seriously, the future is not a concern, but "right here right now". In
the real world, in the business, things are changing VERY slowly, software
is not updated for years/centuries. If the version CVS 1.10.9 would not have
locks I don't care - I am 99% sure my company will not change it from 1.10.7
for two or three years.
> > I do not suggest to use locks all the time, but it is there, it works,
>and
> > you might need it...
>
>I did not suggest that you did. I mearly wished to have a nice detailed
>analysis of the current documentation of "locking/reserverd checkout"
>support within CVS.
NOPE, detail analisis is not what I said. I gave the clues. The interested
parties can also look it up and make their choices. THe question was simple
- can I lock the stuff? The answer is simple: YES, use the locks.
>Very true. However, most tools also have one or the other side that they
>do better. CVS does the non-locking stuff better than the reserved/locking
>stuff. At least my experience has taught me that...
TRUE.
> > The right tool for the right job.
>
>In this case, I'd say that if your *WHOLE* development model depended on
>reserved checkouts, then CVS is not your tool of choice. (...)
OK, now is the good time to talk about the future. What if I want to start
with the locking model and later on change it to the concurent one?
Migration from one model to another is important, and even more important
than the software future itself. It is because I care how much I can change
WITHOUT updating the version of s/w. So, if CVS will drop off the support
for locks, it is likely to disappear or at least loose many new users, just
because the migration would cost too much...
BR,
Jerzy
Lars-Christian Schulze
> ...
> Here's the diff against cvs-1.10.7. Note that this hasn't been incorporated
> into the standard build and should be considered experimental.
>
Thank you for the patches.
> ...
> >On the other hand I find locking very useful when editing binary files,
> >e.g. Winword documents. (Yes, I know it is possible to merge Winword
> >files, but that's no fun.)
>
> Why won't communication work?
>
In general communication between my colleagues and me works very good. I
would see the locking mechanism as some kind of support not to
accidentally change a file concurrently.
> ...
> If I understand the mechanism correctly, "cvs admin -l/-u" doesn't prevent
> another user who already has the file checked out from modifying that file,
> updating it (ie merging it with changes from the repo) once the file has been
> unlocked, and checking it back in.
As far as I have tested, it is not possible to check in a file if somebody
else has locked it. If the file is not locked, of course, everybody can
check in a new revision.
>
> IMHO, communication is a much more powerful tool than the admin feature 'cos
> this feature (and any strict locking in fact) tends to give false security.
>
I do fully agree with you. Good communication and good concepts are much
more important and much more powerfull than highly sophisticated tools.
Because we are writing software for aircrafts, we have some restrictions
due to the ISO 9000 and certification stuff. But ISO 9000 does not
prescribe tools, it mainly demands concepts. That's one of the reasons why
I find CVS very usefull for us, because we could integrate it in a
concept, which fits exactly our needs.
But other colleagues want to have a plug 'n play tool with locking, access
control, integrated data base interface and ... and ... and. I admit that
this has some advantages at the first glance, but from my point of view it
has always been better for a long term solution to do things by ourself.
Lars
-------------------------------------------------------------------
aerodata Flugmesstechnik GmbH Email sch...@aerodata.de
Lars-Christian Schulze WWW www.aerodata.de
Hermann-Blenk-Str. 36 Voice +49 531 2359-188
D-38108 Braunschweig Fax +49 531 2359-158
Lars-Christian Schulze
> Hi Lars,
>
> >In my oppinion locking is a mandantory requirement for any good version
> >control tool. E.g. if there is a strict requirement from the project /
> >quality management to use locking for development, period ! So I have to
> >use
> >locking or I have to use another version control tool.
>
> Management should not force the development to use the tool in the wrong
> way. CVS is not the management tool - if you have to deal with this kind of
> management I can only tell you one thing: Run, run away as soon and as far
> as you can! ;)
> ...
Let me add a short comment to this item. Because we are developing
software for aircrafts we have to obey ISO 9000 and all the other
certification stuff. This imposes some restrictions and some very hard
requirements on us. From my point of view it would be possible to use
CVS, because it has some really nice features that will fit our needs
exactly. But if our project management decides to use locking I must
accept this decision, because it makes sense to a certain degree.
In my oppinion the watch mechanism is a good compromise and maybe I can
persuade my colleagues, but if not I must accept that they have their
reasons for their decision.
Noel L Yap
>I do not suggest to use locks all the time, but it is there, it works, and
>you might need it...
>locks quite often have the 'concurent' model as an option. Both models
>(Concurent and 'locked') have it's good and bad sides, and it all depends
>what you doing.
>
IMO, the right tool is "cvs edit", not "cvs admin".
Noel
Noel L Yap
>NOPE, detail analisis is not what I said. I gave the clues. The interested
>parties can also look it up and make their choices. THe question was simple
>- can I lock the stuff? The answer is simple: YES, use the locks.
You should've said so explicitly (even though they should've known implicitly).
Spreading misinfo (including incomplete info) about a tool is a sure way NOT to
get it used in a company. Give the whole truth (including shortcoming) about
the tool. Hopefully, any shortcomings aren't too important.
>OK, now is the good time to talk about the future. What if I want to start
>with the locking model and later on change it to the concurent one?
>Migration from one model to another is important, and even more important
>than the software future itself. It is because I care how much I can change
>WITHOUT updating the version of s/w. So, if CVS will drop off the support
>for locks, it is likely to disappear or at least loose many new users, just
>because the migration would cost too much...
Use "cvs edit -c". Migration cost is whatever it takes to get people to use
"cvs edit -c" instead of "cvs admin -l". This can be forced by creating the
group "cvsadmin".
Noel
Noel L Yap
>In general communication between my colleagues and me works very good. I
>would see the locking mechanism as some kind of support not to
>accidentally change a file concurrently.
Great! CVS should be an easier sell then.
>As far as I have tested, it is not possible to check in a file if somebody
>else has locked it. If the file is not locked, of course, everybody can
>check in a new revision.
I plan to add a "cvs ci -c" option that'll check if the committer has a valid
edit on the file(s). "cvs edit -c" with "cvs ci -c" should provide a good
belt-and-suspenders approach.
>Because we are writing software for aircrafts, we have some restrictions
>due to the ISO 9000 and certification stuff. But ISO 9000 does not
>prescribe tools, it mainly demands concepts. That's one of the reasons why
>I find CVS very usefull for us, because we could integrate it in a
>concept, which fits exactly our needs.
>
>But other colleagues want to have a plug 'n play tool with locking, access
>control, integrated data base interface and ... and ... and. I admit that
>this has some advantages at the first glance, but from my point of view it
>has always been better for a long term solution to do things by ourself.
I've never had any experience with CVS on a project of this scale. Hopefully,
someone else has (and hopefully, it was a good experience).
Noel
Jean-Luc Simard
I just noticed that the -l switch in cvs admin does not stand for local
(non recursive mode), but for lock. Is there a way to make cvs admin run
in a local more only? We use it to change the state of files in a
directory, but don't want to change the state of all files when tha command
is executed from the top of the tree.
Thanks for your help,
Jean-Luc Simard
Matrox Graphics Inc.
Larry Jones
>
> I just noticed that the -l switch in cvs admin does not stand for local
> (non recursive mode), but for lock. Is there a way to make cvs admin run
> in a local more only? We use it to change the state of files in a
> directory, but don't want to change the state of all files when tha command
> is executed from the top of the tree.
Unfortunately not. You'll have to explicitly name the files rather than
just naming the directory if you don't want it to recurse. Something
like the following might be useful:
for file in ${DIR}/*; do
test -f "$file" && cvs admin "$file"
done
-Larry Jones
Like I'm going to get any sleep NOW. -- Calvin