--- "Greg A. Woods" <[EMAIL PROTECTED]> 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
