On Wednesday, March 8, "Cameron, Steve" wrote:
> Bergur Ragnarsson writes:
> >
> > I'm using CVS 1.10 and I am quite happy with it; however there is one
> > very important feature missing:
> > CVS rename
Very true. 'cvs rename' is missing. There are a number of ways to implement
that feature, however, I don't see much point in actually doing it, unless it
is done well. A poorly implemented 'cvs rename' is worse than what is there
now. At least I believe so, entirely IMHO of course.
> > 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.
A very good, and I'd say necessary goal, especially with WinCVS and other
things like that out there...
> > 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)
How do you detect conflicts with this method? IE: Two different RCS files
in the repo specify the same name-location.
> > 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.
Yes, but how do you implement "cvs status"? The mapping is only forward,
from RCS repo file, to sandbox file. In order to have a reverse mapping
for this (unless I missunderstand), you would need to keep extra information
about each file in the sandbox in a CVS/Entries or like file...
> > * All information is still stored in one file only.
This would mean extensive searching to implement "cvs status", as
the current filename may not be what is there in the repo...
--Toby.
