Bergur Ragnarsson writes:
(and I'm moving this thread over to info-cvs rather than bug-cvs, because it
seems
more appropriate, to me.)
> Hello all,
>
> I'm using CVS 1.10 and I am quite happy with it; however there is one
> very important feature missing:
> CVS rename
[smc] [...snip...]
> To implement rename a name-location fields needs to be added to the
> standard revision information (author, date, state, log). This fields
> can be added in several ways:
> * use an existing fields (i.e. author).
> * use special symbol (dirty !?)
> * add a new fields in such a way that the currrent rcs parser
> would ignore, i.e. not complain about - maybe not possible !?
> >> Making the rcs file format backwards incompatible should be
> avoided if at all possible.
>
> Modifications:
>
> 1. Add name-location field that is associated with every revision (like
> author). The location fields would be a path name starting from CVS_ROOT
> - it would not include CVS_ROOT path prefix => easy to relocate
> repository.
> * the location in the latest revision would be in sync with cvs
> repository location
> * the name in the latest revision would also be the name of the
> file in the cvs repository
>
> 2. cvs checkout:
> find revision
> check if name-location field exists, if so check file out to
> that location and under that name
>
> 3. cvs rename
> insert pending name and location change
>
> 4. cvs commit
> (this should be integrated in rcs)
> move the updated file to the new name-location (often no change)
>
> The design has two important attributes:
> * The cvs repository will look the same for the main branch for
> this new cvs and the current one. This means that when a user looks at
> the repository, he sees the most recent layout - which is natural.
> * All information is still stored in one file only.
>
[smc] It would also have this (undesirable) attribute.
suppose I have a repository with two modules, MOD1 and MOD2 which
are subdirectories of a directory called EVERYTHING.
I can do
cvs co EVERYTHING
cd EVERYTHING/MOD1
echo whatever > file1
cvs add file1
cvs commit -m 'x' file1
cvs tag tag1 EVERYTHING
cd ..
mv MOD1/file1 MOD2/file1
cvs rename MOD1/file1 MOD2/file1
cvs commit -m 'moved file1 to MOD2 from MOD1'
cd ..
rm -fr EVERYTHING
cvs co -r tag1 MOD1
...uh oh! file1 doesn't appear!
This is due to your proposed modification #4, above, and to the way
that "cvs checkout" is designed. Or did I miss something?
For you proposal to work, probably you'd want to store the files in
some directory structure which didn't necessarily resemble the
layout
after a "checkout", since, in this case, "cvs checkout" would have
to look
inside every file in the repository to determine whether each file
was part
of the module being checked out at the time the specified tag was in
effect. That is, if you just mv the "*,v" files around, you have to
rather
drastically change how "cvs checkout" works. (and update, & export
too,
I guess... and "cvs tag" too... tons of stuff it would seem.)
-- steve
