[Top][All Lists]

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

[Gnumed-devel] comments about cvs stuff

From: David Grant
Subject: [Gnumed-devel] comments about cvs stuff
Date: Tue, 18 Nov 2003 21:41:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.4) Gecko/20031106

Just some general comments:

DISCLAIMER: I do not know the repository very well, nor do I know everything there is to know about gnumed thus far, so I have probably made some assumptions in what I say. Please tell me if I am wrong. I have some exp. using CVS and some recent exp. setting up a repository and trying to come up with some CVS guidelines and for a voluteer project I'm working on.

I'm not sure if I agree with the philosophy of sticking stuff in a test-area and then moving it back. If something is already IN the main directory of the repository, modifications should be done in a checked out version in the users working directory, and then comited in there. Moving the files to test-area encourages a "commit infrequently" policy.

I think files should be "cvs remove"d and "cvs add"ed as few times as possible. As far as I can remember, it is a nightmare to move a file like $MAINDIR/subdir/test.c into $MAINDIR if there is a file $MAINDIR/test.c already there which may have been modified. If you're going to change a file, no need to move it anywhere. Just edit it there. "cvs update", edit, verify if it compiles and runs, "cvs diff" each changed file individually (I prefer this strongly!), loop back to the first step until satisfied, "cvs commit". "cvs add" and "cvs remove" can make things complicated and I think this is gist of what went wrong in gnumed recently.

Parts of syan's code caused the tree to be broken, led patches to be reverted (apparently), and led to some files being commited although they had no changes in them, except a new $Log :$ due to a cvs move. I think all this could have been prevented, and syan's reputation been saved, had the above "tips" been followed.

NEW code which is untested could go in the test-area, I guess, although there's not really much point. It might as well go right into the main shouldn't break other stuff, or at least it won't break anything any more than if it was in test-area.

Regular tags of the repository should be made. A few of the files logs I looked at had no tags, so I assume this isn't done so far. Maybe you think you're not ready for an 0_1 tag...but they are a good tool to use anyways.


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

reply via email to

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