[Top][All Lists]

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

Re: "cvs move" command

From: Matt J. Gumbley
Subject: Re: "cvs move" command
Date: Tue, 14 Jan 2003 12:48:44 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408

J wrote:
I see the difficulty with that. But how about if you wanted to move a file
to somewhere else on the same branch? Can this be done directly in the
reposity by moving the directory? Is that not a good idea either?

"Pierre Asselin" <address@hidden> wrote in message

In <address@hidden> Stewart Heitmann

<address@hidden> writes:

I would love the CVS development team
to develop a "cvs move" command to
replace the clunky "cvs remove" + "cvs add".

I suggest a "cvs move [srcfile] [destfile]"
command that copies the repository srcfile,v
file to destfile,v in the repository (thus
the new file retains its revision history).
Then it does a cvs remove on the original
srcfile so it can be reinstated later if needed.

It also needs to remove all tags from destfile,v .  Except if this
is happening on a branch, in which case destfile,v should still
have the tag for that one branch.  Does the copy happen immediately,
or is it just scheduled to happen on the next commit, like add and
remove? Is there an extension to the client-server protocol?  Is
the new protocol backward-compatible?  Do new clients interoperate
cleanly with old servers?

cvs move would be very popular. Perhaps it shouldn't remove all tags?

I've currently got a problem with moving files in CVS; not sure if this is the problem you're discussing, and I don't know about branches... please forgive me if I ramble...

In version 1 of our code, we have a file in a directory, say 'directory/file'. Looking in the repository, I see from file,v:

head    1.2;
locks; strict;
comment @# @;

So I've rtag'd Version_1, committed a change to the file, and rtag'd Version_1a. This is fine. However, for Version 2, we need to move the file into 'directory/subdir' (we're refactoring)

Following the advice in Karl Fogel's CVS book (p.230):

1) In the repository, I copy (not move) file,v into its new location:
$ mkdir subdir
$ cp file,v subdir

2) In a working copy, do:
$ rm file
$ cvs remove file
$ cvs commit -m "removed file" file

So the CVS/Entries file in my working copy now just contains 'D', and the file,v in the repository has been moved to the Attic with state of 'dead'.

3) Then in the working copy, do:
$ cvs update -d
cvs server: Updating .
cvs server: Updating subdir
U subdir/file

I then commit a change to the moved version. Now the dead version in the Attic and the live version are both at revision 1.3.

Now I rtag the repository at Version_2. directory/subdir/file,v says:
head    1.3;
locks; strict;
comment @# @;

I now checkout Version_1a, and see the same version of the file as directory/file and directory/subdir/file - the former is fine; the latter location didn't exist at Version_1a.

I now checkout Version_2 and see the file in directory/subdir/file, with the version 2 changes, as expected.

Now I presume that in order to checkout the two versions of this repository with the files in the right place for the given version, I'm going to have to hand-edit the directory/subdir/file,v when I copy it to its new location, to indicate that its first tag is Version_2 and that it shouldn't exist in the earlier versions.

I changed directory/subdir/file,v to:
head    1.3;
locks; strict;
comment @# @;

Then I checked out Version_1a, and it looks OK; cvs status gives me:
File: file              Status: Up-to-date

   Working revision:    1.2
Repository revision: 1.2 /master_cvs/cvsmovetest/directory/Attic/file,v
   Sticky Tag:          Version_1a (revision: 1.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

But have I covered everything?

Kind regards,

reply via email to

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