gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] (no subject)re: reverting


From: David Grant
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:
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 this
      
What 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).

Karsten
    
I 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.
"But if for some reason the file was moved and later moved back the one with the lower numer is actually newer"

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.

some directory:
test.c has revisions 1.1, 1.2, 1.3

another directory:
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









reply via email to

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