[Top][All Lists]

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

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

From: Greg A. Woods
Subject: Re: address@hidden: Re: rename in cvs]
Date: Sun, 14 Oct 2001 12:26:42 -0400 (EDT)

[ 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.

>  Unless a single shop uses multiple versions of CVS
> at once, there won't be any consistency problems with regard to the
> use of the new metadata.

consistency problems aren`t the issue here, though of course if there's
any bug in the current CVS that would cause it to trip over the extended
non-standard metadata then such issues would instantly arise.....

> 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.

The fact that CVS is simply a wrapper for RCS (even if only conceptually
now) is one of its major features!  (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)

>  CVS users aren't supposed to have direct
> access to the repository anyway.

Well, it depends, but that's not really the issue.

>  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.

> 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.

>  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?)

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

>  (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.

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

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