On Thu, 30 Sep 2004, Ceki G�lc� wrote: | Endre, | | | You are correct to observe that directly moving or removing history | files (,v files) in the CVS repository causes problems with the | existing work copies that users have checked out. Thanks for the | heads up.
Actually, that's not what I'm referring to.. But that is definately also an issue! ;) | | However, contrary to common belief, the *moved* history files are | perfectly functional. This I do know: Each ,v-file is self-contained. My point is that if you check out log4j from e.g. 2004-03-25 (for "historical reasons": you have this customer's project using log4j versjon X.y, you only have the jar-file, and you'd like to hack the config-parsing to satisfy some weird immediate requirement from the customer), this checkout will not build anymore. The reason for this, is that the dir-layout, and the javafiles, now have changed: the lf5 ones aren't there anymore. The build.xml file (or whatever) will refer to directories and java files that aren't there! (Basically, if you, after simply deleting all the lf5 dirs from a fresh checkout, have to do -anything- to get the build finished, you're in trouble, "history-wise"..) | | In order to ensure a smoother transition, one could *copy* the history | files to log4j-attic and then perform a *CVS remove* operation on the | LF5 files as they exists currently in the log4j CVS repository. This is a much better approach. The new "log4j-attic" thing will have a "code-history" dating way-back, but won't have a proper "build history" untill from the point at which you check in a build-file that can build the code and make the lf5 jar. | | This way, we would get rid of LF5 in our regular work environment and | still keep its history elsewhere for those who may want it. | | Make better sense? I really don't see the need for the copy-operation at all. The Attic in CVS work like this already: assuming that no-one will pick up the lf5 system in some time, it doesn't really matter if it is accessible only by checking out the log4j repo from before 2004-09-30. Even if people want to start maintaining and updating the lf5 system, they'll just check out a copy of the repo from 2004-09-29, add the lf5 files into a fresh HEAD-copy of the repo, get it up and running, and then it can be re-added, thus it'll get out of the Attic. The copy-operation you suggest can be delayed to whenever someone wants to "fork out" the lf5 project. In any case, I personally advice against deleting -anything- from the CVS repo: I believe that "build history" also must be maintained, or else the history-aspect (the "way back" aspect, not just "rollback") of a SCM system isn't much worth. "cvs remove" is what you most often want. Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
