Facetious comments are not usually appreciated. I am sure GNU would like to
maintain some level of professionalism.
Apparently I have not made myself very clear.
WinCVS 1.06 utilizes a type of GUI display interface with windows,
icons, radio buttons.... I hope everyone
agrees on that at least. As for statement 1, if you
select a file that is at revision 1.3.2.2 and then
click the lock icon, the response that is generated in the
command window is done, with a normal code of 0. There is no
message that a lock was accomplished on that revision of the
file. If I knew "why not" I would not be asking if anyone else did.
As for statement 2,
Platform is again WinCVS 1.06 running on a NT workstation with no custom
scripts.
Here is a sample for you. 1.6 is the current revision of CabsDBClass.java.
I did a update selection to the branch 1.3.2.2.
I selected the file revision 1.3.2.2 and clicked the lock button. The
response was
that revision 1.6 is locked, not the 1.3.2.2 I had highlighted when I
clicked the lock button. Does that not sound like the lock for the branch
is not working. Is this perhaps a misstatement and it should read all
revisions
of the file are locked, or can someone else modify a different branch of
this file?
Either way, I did not get the same results in you example, but then I have
no idea
if you performed the same steps I did. You can see what I get below.
cvs admin -l CabsDBClass.java (in directory
D:\CVSROOT\billstest\billstest\com\nsc\SecabsClient\)
RCS file:
/usr/local/cvsroot/billstest/billstest/com/nsc/SecabsClient/CabsDBClass.java
,v
1.6 locked
done
*****CVS exited normally with code 0*****
cvs log CabsDBClass.java (in directory
D:\CVSROOT\billstest\billstest\com\nsc\SecabsClient\)
*****CVS exited normally with code 0*****
Rcs file :
'/usr/local/cvsroot/billstest/billstest/com/nsc/SecabsClient/CabsDBClass.jav
a,v'
Working file : 'CabsDBClass.java'
Head revision : 1.6
Branch revision :
Locks : strict
1.6 : 'stul1226'
Access :
Symbolic names :
1.3.0.2 : 'testoflockbranch'
1.3 : 'testoflock1'
1.1.1.1 : 'arelease'
1.1.1 : 'avendor'
Keyword substitution : 'kv'
Total revisions : 9
Selected revisions : 9
Description :
----------------------------
Revision : 1.6
Locked by : 'stul1226'
Date : 2000/7/11 14:43:17
Author : 'stul1226'
State : 'Exp'
Lines : +2 0
Description :
test of lock 5
----------------------------
Revision : 1.5
Date : 2000/7/11 13:10:3
Author : 'stul1226'
State : 'Exp'
Lines : +2 0
Description :
test of lock 4
----------------------------
Revision : 1.4
Date : 2000/7/11 12:58:18
Author : 'stul1226'
State : 'Exp'
Lines : +1 -1
Description :
test of lock 4
----------------------------
Revision : 1.3
Date : 2000/7/11 12:56:16
Author : 'stul1226'
State : 'Exp'
Lines : +0 -1
Branches :
1.3.2
Description :
test of lock 4
----------------------------
Revision : 1.2
Date : 2000/7/11 12:55:49
Author : 'stul1226'
State : 'Exp'
Lines : +1 0
Description :
test of lock 4
----------------------------
Revision : 1.1
Date : 2000/6/13 14:59:51
Author : 'stul1226'
State : 'Exp'
Lines : +0 0
Branches :
1.1.1
Description :
Initial revision
----------------------------
Revision : 1.1.1.1
Date : 2000/6/13 14:59:51
Author : 'stul1226'
State : 'Exp'
Lines : +0 0
Description :
no message
----------------------------
Revision : 1.3.2.2
Date : 2000/7/11 13:1:7
Author : 'stul1226'
State : 'Exp'
Lines : +1 0
Description :
test of lock 4
----------------------------
Revision : 1.3.2.1
Date : 2000/7/11 12:59:24
Author : 'stul1226'
State : 'Exp'
Lines : +1 -1
Description :
test of lock 4
===============================================
As for statement 3, when a lock is set on a revision such as 1.4, a
mod is made, and the commit executed there is no message about multiple
locks. Revisions 1.3 and earlier are not locked like they are if the
same steps are performed on a 1.1.1.1 revision. The revision number is
incremented to 1.5 and the lock is removed. That works fine, but,
as I said before the only way that a locked 1.1.1.1 revision can be
committed is if the locks are manually removed from both 1.1 and
1.1.1.1 via command line and then the commit completed.
The unlock GUI button does not unlock either the 1.1 or 1.1.1.1 file
once a mod is made. However, if you lock then unlock the same file without
making a change it will work. So, unles there is a bug in only my
unmodified
version 1.06, then it may not work as well as you think.
I was also under the impression, after reading other postings, that this
would
be a typical request for a info-cvs group, or was I mistaken?
TTFN
-----Original Message-----
From: Matthias Kranz [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 10:55 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Patches or work-arounds requested for lock problems
On Tue, Jul 11, 2000 at 01:36:01PM -0000, [EMAIL PROTECTED] wrote:
> More questions and request for patches anyone may have created
> for lock/unlock problems. What I have found is that:
> 1. lock/unlock does not work for branches
Why not?
> 2. locking a first revision i.e. 1.1.1.1 will show (when a log
> of the file is requested) that only 1.1.1.1 is locked.
Sure.
> Try to
> make a change then commit and the message that multiple
> revisions are locked is displayed. If a log is done both
> 1.1.1.1 and 1.1 are locked. Unlock 1.1 with the command
> line, try and commit, and again the multiple lock message
> is generated and 1.1 is again locked.
What are you talking about? Please provide us the information, which
tools you are using. Are you speaking of a graphical user interface?
This is the info-cvs mailing list, which is for CVS in general and not
for any GUI in particular.
> 3. After the initial delivery of a file is completed and the
> revision number is incremented past 1.1.1.1, locking works
> with the exception of branches.
>
> Does anyone know of any pathes that will fix this problem?
Nothing to fix, it works.
cvs2@gromit:~/testrep > cvs admin -l1.2.2.1 file6
RCS file: /usr/local/repository/testrep/file6,v
1.2.2.1 locked
done
cvs1@gromit:~/testrep > cvs ci -m "test" file6
cvs [commit aborted]: Revision 1.2.2.1 is already locked by cvs2
cvs2@gromit:~/testrep > cvs admin -u1.2.2.1 file6
RCS file: /usr/local/repository/testrep/file6,v
1.2.2.1 unlocked
done
Cheers,
Matthias
--
Matthias Kranz [EMAIL PROTECTED]
http://www.belug.org/~kranz
"Ever tried. Ever failed. No matter. Try again.
Fail again. Fail better." (Samuel Beckett)
