[Top][All Lists]

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

Re: Consistency check of repository & knowing whether files are being wa

From: Mark D. Baushke
Subject: Re: Consistency check of repository & knowing whether files are being watched
Date: Wed, 19 May 2004 12:37:57 -0700

Hash: SHA1

marko <address@hidden> writes:

> > Nothing comes to mind, but it has been a long day... have you considered
> > a file that has only been added to a branch or removed from the mainline
> > (it will be in the Attic/ directory).
> well, I considerd the Attic/ as a subdir of the repository as all the
> others. The script could iterate through it as usual. But I see that I was
> wrong. The attic doesn't have a fileattr! So it's not so easy.
> That's the kind of snare I expected! :)


> So, I guess, the processing of the Attics would require a parsing of the
> ,v-files, since I assume the watch or edit information there. But perhaps
> I am mistaken. Is it possible to remove a file which is still watched or
> edited. I guess at least the latter should be impossible. Or is the
> information about watches/edits lost in such a case? Anyway, those files
> wouldn't be so important anyway, since they belong in principle to trunks
> which have state 'dead', right?!

The CVS/fileattr directory in the parent may list a foo,v file that is
found in Attic/foo,v .... however, it should not be possible to have
both a ./foo,v and an ./Attic/foo,v in the same tree, so the added
expense is mostly in processing the CVS/fileattr files using a search
path to find the real ,v-file.

> That brings me to the question how can I get information via cvs about
> files being held in attics?

Shortly, on feature the 'cvs ls' or 'cvs rls' command will be useful to
you... Otherwise, using something like a 'cvs log -r1' may be useful.

> Also I do not know what happens if you have several watches on more
> than one revision of a file... Have to test, but expect that to be
> simply appended to the according line in the fileattr file together
> with information which revision is actually in focus.

To be honest, I have not tried it.

> OK, still collecting all these thoughts to get an idea what I have to
> take care of, since I do not really want to screw up my repositories
> with a bad designed tool... Looks like it's not so easy to set it up.

Well, the cvs advisory locking ('cvs watch', 'cvs edit', and 'cvs
watchers') commands are not necessarily as well integrated as might be
desirable. If you find bugs, feel free to send patches...

        -- Mark

Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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