[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem with lock file when committing file

From: Julian Opificius
Subject: Re: problem with lock file when committing file
Date: Tue, 02 Aug 2005 08:18:23 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Andy Jones wrote:
When you checkout against a tag you are effectively checking out "old

Yep, I got that figured :-)

  You can't update them as the latest version without a little

Sorry, I should have said that the tagged revisions are at the head of the trunk ...

Did you actually mean that the versions represented by this tag were
to replace the current versions in all cases?  In which case, you need
to check out the latest versions and then merge them with the older,
tagged versions.  If you've never done this before, be careful: check
out the manual first.

Well as the tagged version is at the head of the trunk, I expected to have no trouble committing a modified file, once I'd updated the directory and removed sticky tags, of course.

My understanding here is that checking out via a tag is a way of defining what goes into the local sandbox directory: if it's a tagged version, that's defining a revision point exactly, so you obviously can't modify and check in a file that was checked out because it was tagged - that would be changing history - one of the major sins CVS is designed to avoid.

No, my primary heartache is the intended location of the lock file in the message, which is not where my configuration keeps lock files - I use /var/lock for that so I can use pserver to prevent unlogged write access to the repository.


On 01/08/05, Julian Opificius <address@hidden> wrote:

A user gave me this problem/sequence of events:

1. user tags some of the files in a directory (successful)
2. user executes checkout against tag to new directory (successful)
3. user edits one file
4. user tries to check in changes (unsuccessful), gets ...
"cvs commit: sticky tag `PL069_V18' for file `uc_interface.vhd' is not a
cvs [commit aborted]: correct above errors first! "
5. I repeat checkout/change process on my own machine, update directory
using clearing sticky tags, and get additional files that were not
tagged, (I don't care about that, though I don't know what I should have
done to not get the other files)
6. I try to to check in changed file, and get ...
cvs [commit aborted]: could not open lock file
Permission denied"
Which is a real problem, because I have CVS server configured to put log
files in /var/log/cvs, not /usr/local/cvsroot.

Can anyone give me insight into what we're doing wrong here?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]