[Top][All Lists]

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

Re: address@hidden: Re: rename in cvs]

From: Paul Sander
Subject: Re: address@hidden: Re: rename in cvs]
Date: Sun, 14 Oct 2001 21:56:45 -0700

>--- Forwarded mail from Greg Woods:

>[ On Sunday, October 14, 2001 at 01:49:56 (-0700), Paul Sander wrote: ]
>> Subject: Re: address@hidden: Re: rename in cvs]
>> Assuming that some kind of rename capability is built into CVS that
>> stores additional metadata in the repository, then THAT version of
>> CVS would become the standard.  And presumably, the new standard CVS
>> would also provide a means to at least examine and perhaps modify
>> the new metadata.

>That's not how the real world works, and you should know that by now.

Which part?  The part that each shop adopts one version of its tools
at a time (and that that version is fairly up to date), or the part that
tools provide access to their meta-data?

Everyone I know goes to great effort to use just one (recent) version of
the tools that provide their process infrastructure.  The tools usually
provide some kind of access to examine their data, and the good ones
provide admin functions to modify them, usually in the name of error
recovery after corruptions.  This does not necessarily mean that the
format of the file is published, only that the data can be read and
modified in a correct and coherent way.

>> As for RCS, who cares?

>Excuse me?  Everyone _should_ care, and I for one certainly care an
>incredible amount.  I was only placated into accepting the integration
>of RCS management inernally to CVS because it meant there could be an
>incredible boost of performance in some circumstances (eg. those where
>multiple external operations were previously required).  I still worry
>about the differences in implementation and the supposedly innocuous
>differences in resulting RCS file contents.  If I'd had the time I would
>have contributed code and tests to ensure that CVS produced ,v files
>indistinuishable in every way from those produced by doing the same
>operations with plain RCS.  Maybe someday someone will still get around
>to doing this.

Why are you so concerned about CVS internal format?  Do you do stuff
to the repository outside of CVS?  If you do, then shame on you; best
practice is to use CVS' interfaces exclusively.

>The fact that CVS is simply a wrapper for RCS (even if only conceptually
>now) is one of its major features!

The fact that CVS used RCS is an artifact of its implementation.  At
the time that CVS was designed, the authors needed a tool that did text
deltas, and RCS was the only one freely available at the time that was
stable enough to use.  CVS continues to use the RCS file format to
keep itself compatible with existing repositories.  And there is
precedent for adding new metadata; CVS did not always track "dead"
versions, and the fact that the version "state" attribute is used
now has the possibility of causing grief in cases where the RCS
files are maintained by two different systems.

>(and it's not just because you can
>move RCS projects easily into CVS -- but also the other way around, and
>not just back to plain RCS, but to other tools that might use RCS as an
>underlying repository structure)

Even if some new metadata are adopted, both transfers will continue to
work as well as they do today.  The ,v files copied into a CVS repository
will still be compatible with CVS.  The fact that the pointers that
implement a rename capability will be absent just means that no renames
have been done.

As for going the other way, tools that read RCS files will still have
the same data they get today.  They'll also get more that they won't know
what to do with.  If they were implemented according to the RCS standard
then they should ignore the CVS metadata, or perhaps set some kind of
attribute and carry it in without interpretation.  If the tool breaks,
then report it as a bug or write a filter to remove the CVS meta-data.

>>  And if for some reason someone
>> really does need to read the contents of the CVS repository using
>> RCS, perhaps as a means to converting to something else, who cares?

>Anyone with any long-term investment in CVS _should_ care.

If CVS provides interfaces to all of the metadata it uses that are
stored in the RCS files, and users do not have direct access to
the CVS repository, then why would they care that the repository
is in RCS format?  It's just an implementation detail that's hidden
from them.  (Well, "cvs status" hints at RCS files that are somehow
related to the sandbox, but again the user has no access to it anyway.)

>> RCS can still process the stuff it knows about.

>Of course -- that's the problem because the new, and in this case
>incredibly important, metadata is effectively hidden from its view.

It's only important for features that fall outside of RCS' pervue.
RCS still operates just fine on what it understands.  If the new
metadata are important to you, then use the tool that manages it:

>>  Whatever process
>> lives outside of RCS will be ignorant about the new metadata and
>> won't use it anyway.

>Of course -- and that wouldn't be as big a problem if it didn't affect
>the fundamental structure of the repository.

>(or perhaps you don't care about the renamed files when you go to
>recover your CVS repo and/or convert it to some other format?)

Recover the CVS repo...   That suggests that I should have good
backups.  I do, and so should everybody else.  If by "recover" you
mean to repair corruptions in the absence of a suitable backup, then
certainly this adds to the complexity.  But it's not much more
difficult than recovering dead versions and deciding the properly
location of the RCS files (i.e. whether or not the RCS files belongs
in the Attic or not).

As for converting to some other format, the conversion is imperfect
as it is.  Companies that provide tools to convert from CVS to their
format will need to update their tools.  In any case, CVS has not
traditionally provided tools to assist with conversions to competing

>yes CVS won't go away or be unusable in the same way that could happen
>to commercial software, but that doesn't change the fact that RC

Sorry?  That sentence was garbled.  Would you repeat your point, please?

>>  (If someone uses RCS to modify the repository,
>> then it's certainly possible to get the new metadata wrong.  But
>> again, who cares?  CVS repositories should be modified only by CVS
>> anyway.)

>That's where you're going wrong in your thinking here I think.

>Yes during production CVS repositories should only be modified by CVS.

>However that's not the only concern of anyone with an investment in a
>CVS repository.

Would you name a few concerns that people may have, other than having
complete access to all of CVS' metadata via CVS' interfaces, and IT
concerns (i.e. keeping the repository's filesystem robust, without
concerns for the internal format of the files)?

>--- End of forwarded message from address@hidden

reply via email to

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