[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" <pa@panix.com> wrote in message
news:avhtuu$ka0$1@reader1.panix.com...
In <mailman.47.1041996457.21513.bug-cvs@gnu.org> Stewart Heitmann
<S.Heitmann@lake.com.au> 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;
access;
symbols
Version_1a:1.2
Version_1:1.1.1.1
start:1.1.1.1
mgumbley:1.1.1;
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;
access;
symbols
Version_2:1.3
Version_1a:1.2
Version_1:1.1.1.1
start:1.1.1.1
mgumbley:1.1.1;
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;
access;
symbols
Version_2:1.3
start:1.1.1.1
mgumbley:1.1.1;
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,
Matt
Re: "cvs move" command, Kaz Kylheku, 2003/01/21