Essentially, I am version controlling a website. As such files, assets, etc.
get added and removed. On our live site, all files are checked out with the
tag 'live'.
On our development server, users tag files they want to go up to live and a
cron job does periodic cvs updates.
So, from time to time, the tag 'live' moves from revision to revision over the
course of the file's life. The problem is that when you remove a file, the tag
persists and the file stays on the live site. Previously, I had just deleted
the tag from the file. For simple dev/live development, this works fine.
The problem occurs when doing more sophisticated developemnt. We have
essentially 5 layers - 1 where developers work, 1 where files are merged and
assembled for QA, 1 where QA happens, 1 where the client approves changes and 1
for the live site. This means 3 or 4 tags are needed (dev,qa,stage,live, dev
could be omitted).
So, when I remove a file, I'd have to delete ALL those tags from it.
Effectively pushing my change from development to live w/out going through QA
or client approval.
I could delete the tags at each step, but this is not so simple, and CVS
provides a better way:
When I remove a file, I move the 'dev' tag to the newly created 'dead'
revision. Then, to move from dev to qa, I point the 'qa' tag at whatever 'dev'
points to, which is the dead revision, which causes the file to be removed from
QA. The same process is used for stage and live.
Of course, doing that is difficult because CVS will only tag a dead revision if
you specifically tell it to via the -r or -D flags, whereas all other revisions
are tagged implicitly when issuing the 'cvs tag' command.
For cvs log or cvs stat, it's nice to run those commands in a directory, parse
the output, and show a report or UI to a user. Since cvs pretends removed
files don't exist, you can't get them to show up except by explicitly
requesting information. Since they aren't there, you don't know the names of
the files to request! Catch-22!
The overall point is that I see no advantage to the current implementation and
it actually makes doing certain things with CVS very difficult. It would be
nice to know the reason why it acts this way, and if there is a problem with
providing a flag to do the behaviour I describe.
Dave
On Wed, Feb 16, 2000 at 08:18:42PM -0500, Greg A. Woods wrote:
> [ On Wednesday, February 16, 2000 at 14:43:26 (-0800), |}avid (opeland wrote: ]
> > Subject: Why does CVS treat removed files so specially?
> >
> > Note that main.c DOES NOT get tagged.
>
> It's not supposed to be.
>
> Tags are used primarily to tag "releases" (i.e. to give a symbolic name
> to all of the revisions of a specific version of the module). (Well
> that and to name branches too.) Since a removed file no longer exists
> in the "current" version of a module you don't want it to be a member of
> a current release -- which it would be by definition of having a tag.
>
> If you do want the file to be present in the current release then don't
> remove it. :-)
>
> > Even if you 'cvs tag -F some_tag main.c'
> > it does not get tagged.
>
> You don't ever want it to be tagged. Trust me!
>
> > You can ONLY tag the new (dead) revision, via
> > 'cvs tag -r 1.2 main.c',
>
> You definitely do not want to do that. You never want to have a tag on
> a 'dead' revision! All hell will break loose! Well, maybe not that
> dramatic, but it'll sure screw up your release management.
>
> > also, doing commands like 'cvs log' and 'cvs stat' (with no file arguments) do
> > not produce output for removed files.
>
> I should hope not. (well actually they will if you ask them to report
> on a revision of the file that did exist previously with '-r' or '-d')
>
> > This makes it extremely difficult to do ANYTHING in batch mode with CVS
>
> I use CVS in batch mode almost all of the time and it works perfectly
> for me! ;-)
>
> What exactly is it that you are trying to accomplish? Perhaps if you
> can describe your requirements one of us can either explain how you
> might go about meeting them with CVS, or suggest an alternative
> approach.
>
> > and I
> > can think of no explanation for it (other than convienience while coding CVS
> > features/throwback to RCS).
>
> Check out the "Attic" node of the manual.
>
> > At the very least there should be an option to cvs that says "Run the command
> > on removed/dead revisions"
>
> No, I don't think so!
>
> --
> Greg A. Woods
>
> +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
--
David Copeland
Software Engineering Director
NOVO
Relationship Architects for e-Business
Voice 415 646 7026 | Fax 415 646 7001
http://www.novocorp.com
