[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: renames under CVS
From: |
Noel Yap |
Subject: |
RE: renames under CVS |
Date: |
Wed, 27 Feb 2002 06:27:48 -0800 (PST) |
--- "Greg A. Woods" <address@hidden> wrote:
> [ On Tuesday, February 26, 2002 at 19:50:23 (-0800),
> Noel Yap wrote: ]
> > > We would also need a graph showing how many of
> those
> > > files could be
> > > harmlessly renamed in the repository (i.e. which
> > > have tags and branches,
> > > and which do not).
> >
> > Why would files with tags and branches be any
> > worse/better off than those without?
>
> Files without tags or branches can be safely and
> easily renamed in the
> repository, leaving no evidence that they ever
> existed under the old
> name since that old name is not yet relevant to the
> overall change
> history of the project.
>
> Yes other cleanups in the build
> makefiles/scripts/etc., or #include
> lines, etc., which may have referenced the old name
> will have to be
> adjusted, and the commits of these changes will
> leave traces of the old
> name and when it was obliterated, but in the bigger
> picture these little
> details are irrelevant.
>
> If you actually try this you'll find that it's
> possible to prepare a
> working directory with all the necessary secondary
> changes, and to
> commit those just prior to making the move in the
> repository itself.
> Everyone else with an active working directory will
> simply "cvs update"
> (and deal with any merges the same way they would if
> the file had been
> renamed using the "add/remove" procedure).
So now you're saying that it's OK to rename the
archive file under certain situations? Wouldn't this
break the build for those who need to checkout by
timestamp?
> Yes some degree of serialization is necessary, but
> even on a large
> project with users working around the clock around
> the world this isn't
> a difficult thing to prepare everyone for (I've been
> part of such a
> change -- it worked just fine with no hitches and no
> complaints and no
> adverse after-effects).
CVS is the _Concurrent_ Versioning System. Hasn't
your stance always been, "One shouldn't be striving
for any degree of serialisation when using CVS"?
> Apply the K.I.S.S.
> principle, do some
> expectation management with your colleagues using a
> touch of T.L.C. and
> then get on with your life and your project! Geez
> man! What's so hard
> about all this? We're dealing with practical
> systems here, not some
> pie-in-the-very-blue-sky dream machine with 100%
> ultimate perfection and
> complete and total error free operation and
> abslolute fool-proof features!
I know you've asked before, "Why are so many people
asking for this feature?" Have you ever asked
yourself, "Why am I the only one defiantly opposed to
such a feature?"?
> > > Finally of course we'd need to find some way to
> assess the difference
> > > between an ideal filename, and one that's
> suitable and sufficient for
> > > the purpose. While we might all like to rename
> many of the files and
> > > directories in our projects, there's no
> fundamental necessity requiring
> > > us to rename files that are not "grossly"
> mis-named.
> >
> > This measure would be extremely subjective.
>
> That's partly my point! ;-)
Then it's not a metric.
Noel
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
- Re: renames under CVS, (continued)
- RE: renames under CVS, Noel Yap, 2002/02/26
- RE: renames under CVS, Greg A. Woods, 2002/02/27
- RE: renames under CVS, Paul Sander, 2002/02/27
- RE: renames under CVS, Noel Yap, 2002/02/27
- RE: renames under CVS, Greg A. Woods, 2002/02/27
- RE: renames under CVS, Greg A. Woods, 2002/02/27
- RE: renames under CVS,
Noel Yap <=
- RE: renames under CVS, Greg A. Woods, 2002/02/27
Re: renames under CVS, Mark A. Flacy, 2002/02/28