|Subject:||Re: [Gnumed-devel] (no subject)re: reverting|
|Date:||Wed, 19 Nov 2003 05:28:15 -0500|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4) Gecko/20031106|
Sebastian Hilbert wrote:
"But if for some reason the file was moved and later moved back the one with the lower numer is actually newer"On Wednesday 19 November 2003 02:47, Karsten Hilbert wrote:I have a guess here. When one moves files from the main trunk to test-area/foo and commits there , revisions start at 1.1 again. Once you move it back it probably continues with previous version in main trunk +1. I have seen thisWhat you describe accounts for downgrades from x.y to 1.1 versions. It does not explain any *upward* gaps in the sequence, though. That could rather be explained by hand-editing the commit history, or perhaps by committing to more than one repository (as David suggested). KarstenI guess you are right. Looking at some of the files it should have been 1.34-1.35->|mv|->1.1->1.2-> |mv| -> 1.3 I never liked the startover in versioning. Makes questions like which revision do you use quite pointless when you silently assume you are talking about a file in the same CVS location. But if for some reason the file was moved and later moved back the one with the lower numer is actually newer. Worse if the startover happened multiple times.
This isn't true. The "old" 1.1, 1.2 revision doesn't exist in the directory that the file is in currently. cvs knows nothing about it. All it knows you did is deleted a 1.1 or 1.2 revision whatever, in one directory, and then you added some file (which happens to be the same file) to another directory. Since that file already exists in that directory, really you're just comitting, so it adds a version number and you get 1.35 or whatever. The 1.1, 1.2 revisions of the file only exist in the Attic of the previous directory that the file is located. If you look at the logs for the files cyan changed in client/business, they don't say anything about the second 1.1 change revision in the "other" directory. Only the $Log: $ revealed that.
test.c has revisions 1.1, 1.2, 1.3
test.c has revisions 1.1, 1.2, 1.3, .... 1.10,1.11, 1.12,1.13
They have the same name, but are completely different as far as cvs is concerned. So I guess if you say the revision 1.1 of test.c in some directory is newer than the 1.12 revision of test.c in another directory. Well who knows? And cvs doesn't know. Which is probably why other patches supposedly got clobbered by syan's commit. Making a copy of a bunch of files and putting them in test-area, and then copying them back to the previous directory later and comitting is a BAD idea. Unless your intent from the beginning is to replace the originals with the new. Otherwise best to work in the main directories, make small changes, update, commit, update commit, provide good commit comments, comment code, etc...
I do not know nothing about concepts so my feeling might be stupid from a technical point of view. Sebastian _______________________________________________ Gnumed-devel mailing list address@hidden http://mail.gnu.org/mailman/listinfo/gnumed-devel
-- David J. Grant M.A.Sc. Candidate in Electrical Engineering a-Si and Integrated Circuits Lab University of Waterloo Room DC3707 519-888-4567 x2872 http://www.eng.uwaterloo.ca/~djgrant
|[Prev in Thread]||Current Thread||[Next in Thread]|