info-cvs
[Top][All Lists]
Advanced

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

Re: Proposal to fix CVS binary file implementation


From: Paul Sander
Subject: Re: Proposal to fix CVS binary file implementation
Date: Fri, 5 Jan 2001 10:56:52 -0800

Eric has some good ideas.  I wonder if we could get Paul Eggert to add
support to RCS to directly fetch and set newphrases, in case someone needs
them someday.

However:

--- Forwarded mail from address@hidden

  - One can imagine adding a per-revision attribute that says
    where in the sandbox this ,v file lives.  Poof -- the
    revision-controlled mapping that Paul Sander (I think) was
    talking about.  (There'd still be a need to map the other
    way, from sandbox name to ,v file -- but maybe the
    CVS/Entries file could do that).

--- End of forwarded message from address@hidden

The mapping is a bit trickier than this because a single RCS file can map
to more than one place in the sandbox, depending on the module that's
being checked out.  I believe that a per-revision mapping stored in the
RCS file is fundamentally incompatible with the modules database because
the modules database can't properly handle a file that has been renamed
out of the module.

Also CVS currently can't handle the case where a single sandbox directory
contains working copies of files collected from more than one directory in
the repository.  The Entries file would have to be modified so that the
fullpath (or path relative to CVSROOT) to the RCS file is stored there.
Unfortunately, Entries field separators are the same as Unix path separators
("/") so this would introduce an incompatible change.



reply via email to

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