On Wed, Jul 12, 2000 at 05:24:04PM +0800, Win32 M$ wrote:
> As a general note - I think you should read the things and try to understand
> what they mean....
I ever try to ... See sginature.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > WinCvs support
> > > Subscribe to the cvs mailing list.
> >
> > ? Please admit, that one could get the opinion that the cvs mailing list
> > is the list for WinCVS support. At least I did, as I read the page.
>
> Please admit that it doesn't say "wincvs mailing list'. Period.
I admit. I am too stupid for this world.
> > Hm, I am on the web for several years now and in most cases, those
> > bottom addresses are associated with the web master ... ;).
>
> ? Do you not read the things just guess what is written there 'in most
> cases'? Feel sorry for yourself then...
Thank you.
You don't want to see the problem. What if you would have two sections
on the web site? E.g.
*** WinCvs support
Any suggestions or problems: [EMAIL PROTECTED]
*** General CVS support
Subscribe to the cvs mailing list.
Go to http://www.cvshome.org
New quoting beginning here ...
> >From: <[EMAIL PROTECTED]>
> >Sent: Tuesday, July 11, 2000 9:36 PM
> >Subject: Patches or work-arounds requested for lock problems
> <snip>
> > 1. lock/unlock does not work for branches
>
> Did you have a locking working on branches? No problem?
No, not as far as I can see.
> >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.
>
> But in the end the whole file with all branches are locked, which sucks
> because the log only tells about one revision and it makes it difficult to
> confirm if the file is locked or not. Status also don't give that info - and
> it should.
> Still no problem?
No. See my paragraph at the bottom of the mail.
> OK, here is the conversation wit the problem.
> I lock the 1.1.1.1, then I can not commit nor unlock.
Hm. See my paragraph at the bottom of the mail.
> cvs -z4 admin -l CvsIn.def (in directory D:\Jerzy\CvsIn)
> RCS file: D:\CVS_LocalRepo/CvsIn/CvsIn.def,v
> 1.1.1.1 locked
> done
Ok.
> cvs -z4 edit CvsIn.def (in directory D:\Jerzy\CvsIn)
> Saved settings for D:\Jerzy successfully...
> cvs -z4 commit -m test CvsIn.def (in directory D:\Jerzy\CvsIn)
> Checking in CvsIn.def;
> D:\CVS_LocalRepo/CvsIn/CvsIn.def,v <-- CvsIn.def
> cvs commit: D:\CVS_LocalRepo/CvsIn/CvsIn.def,v: multiple revisions locked by
> jerzy.kaczorowski; please specify one
> cvs commit: could not check in CvsIn.def
> cvs commit: D:\CVS_LocalRepo/CvsIn/CvsIn.def,v: multiple revisions locked by
> jerzy.kaczorowski; please specify one
> cvs commit: could not unlock D:\CVS_LocalRepo/CvsIn/CvsIn.def,v
Ok, I got the same result. I read what CVS is replying to me: "...
please specify one". I understood what I just read. I thought, "Ok, then
I specify one."
> cvs -z4 admin -u CvsIn.def (in directory D:\Jerzy\CvsIn)
> RCS file: D:\CVS_LocalRepo/CvsIn/CvsIn.def,v
> cvs admin: D:\CVS_LocalRepo/CvsIn/CvsIn.def,v: multiple revisions locked by
> jerzy.kaczorowski; please specify one
> cvs admin: cannot modify RCS file for `CvsIn.def'
cvs admin -u1.1.1.1 file3
or
cvs admin -u1.1 file3
RCS file: /usr/local/repository/testrep/dir1/file3,v
1.1.1.1 unlocked
or
1.1 unlocked
done
cvs ci -m "test" file3
Checking in file3;
/usr/local/repository/testrep/dir1/file3,v <-- file3
new revision: 1.2; previous revision: 1.1
done
> Still no problem?
As far as I can see, the problem that both revisions (1.1.1.1 and 1.1)
are locked, only appears after importing a new project?
Please read Section 4.1 of the Cederqvist. "By default revision 1.1 is
the first revision of a file."
Chapter 13: "Tracking third-party sources"
"The unmodified distribution from the vendor is checked in on its own
branch, the vendor branch. CVS reserves branch 1.1.1 for this use."
Apart from this I get the behaviour which is described in the
Cederqvist, which is what I expect CVS to do. I lock revisions on
branches. Only the specified revisions of the file is locked. Commits to
the main trunk or other branches, revisions are allowed.
So -> no problem.
Regards,
Matthias
--
Matthias Kranz [EMAIL PROTECTED]
http://www.belug.org/~kranz
"Ever tried. Ever failed. No matter. Try again.
Fail again. Fail better." (Samuel Beckett)
