When is it okay to ``cvs remove``?
I am rewriting test_urllib.py from scratch since the current version is very lacking (and out of date; the thing tests against UserDict from odd reason). Since I have written it from scratch I figure doing a ``cvs remove`` on the current test_urllib.py and then adding my new version to get a fresh version numbering? Also, my rewrite is not finished (have some more things I want to test), but what I have so far passes and seems good. Should I bother to check in what I have so far to have it in b1, or hold off until the suite is completely finished? I am assuming since these are unit tests that are passing I don't need to bother with an SF patch to get a code review from someone. -Brett
On Thu, Apr 24, 2003 at 03:43:34PM -0700, Brett Cannon wrote:
I am rewriting test_urllib.py from scratch since the current version is very lacking (and out of date; the thing tests against UserDict from odd reason). Since I have written it from scratch I figure doing a ``cvs remove`` on the current test_urllib.py and then adding my new version to get a fresh version numbering?
That's not particularly useful. The only thing that does is create a period in time (or rather, 'history' -- CVS history) in which test_urllib.py doesn't exist. Re-adding the file won't give you a fresh version numbering either, it'll just give you a lot of headaches, especially when there are branches involved (right, Barry ? :-) Just commit your new test_urllib.py directly, when it's all done, using something like cvs commit -r2.0 test_urllib.py But you probably want to discuss the version number you want to force, Guido might like to reserve 2.0 for something (although I think he should use '3000' instead :) CVS is very 4-dimensional; it only allows for one file to exist at any given spot in the entire timeline. It can leave and come back, but it's still the same file. (And, for example, it can never become a directory.) And a file can have only one 1.1 revision. If you have direct access to the CVS repository (which is actually RCS) you can remove the RCS file and start really a'fresh, but that means you lose history. It's nullifies the file. (and is also about as drastic as Galactus' Nullifier ;-)
Also, my rewrite is not finished (have some more things I want to test), but what I have so far passes and seems good. Should I bother to check in what I have so far to have it in b1, or hold off until the suite is completely finished? I am assuming since these are unit tests that are passing I don't need to bother with an SF patch to get a code review from someone.
It might at least make sense to have some differing platforms run the test
before you check it in.
--
Thomas Wouters
[Thomas Wouters, dispensing good CVS advice]
... Just commit your new test_urllib.py directly, when it's all done, using something like
cvs commit -r2.0 test_urllib.py
But you probably want to discuss the version number you want to force, Guido might like to reserve 2.0 for something (although I think he should use '3000' instead :)
That part I didn't grok: why force an artifical version number? I can't imagine a use for that. The "Rewrote from scratch." checkin comment Brett will surely make is milestone enough in the CVS log.
Tim Peters
That part I didn't grok: why force an artifical version number? I can't imagine a use for that. The "Rewrote from scratch." checkin comment Brett will surely make is milestone enough in the CVS log.
Bumping the major number makes a more visible change. There is no technical reason to do that, nor one to avoid doing so if you like the visible change. A number of files in the Python CVS do have a 2.x version number; I always wondered why that is. Regards, Martin
[Thomas Wouters]
On Thu, Apr 24, 2003 at 03:43:34PM -0700, Brett Cannon wrote:
Also, my rewrite is not finished (have some more things I want to test), but what I have so far passes and seems good. Should I bother to check in what I have so far to have it in b1, or hold off until the suite is completely finished? I am assuming since these are unit tests that are passing I don't need to bother with an SF patch to get a code review from someone.
It might at least make sense to have some differing platforms run the test before you check it in.
OK, I will finish the code then first. Just to double-check, creating a tracker item and initially assigning it to myself will not cause people to ignore it since everyone who cares will see the new item when it gets mailed to Patches and sees I am asking for other people on other platforms beyond OS X to give the code a run, right? And is having new testing suites peer-reviewed a common thing? Or should I only worry about it when there is a slight chance cross-platform issues might sprout up from the tests? I already know to have any questionable code and massive code changes checked, but I also don't want to hold up code I think is good and safe on SF and bug other people to check it for me. -Brett
Brett Cannon
OK, I will finish the code then first. Just to double-check, creating a tracker item and initially assigning it to myself will not cause people to ignore it since everyone who cares will see the new item when it gets mailed to Patches and sees I am asking for other people on other platforms beyond OS X to give the code a run, right?
Wrong; I do ignore patches that are assigned.
And is having new testing suites peer-reviewed a common thing? Or should I only worry about it when there is a slight chance cross-platform issues might sprout up from the tests?
I believe the general policy is that if you are certain that a certain patch is useful and correct, you don't need to post it on SF; that is the case in particular if you are *the* maintainer of that piece of code. So if you have doubts, post on SF - but do ask yourself whether there is anybody who you think could eliminate those doubts; if there is no true expert around, the patch will stay unreviewed forever. The policy about beta releases is (or should be) stricter. No new features, and perhaps no new tests unless they test for a bug that gets fixed. So in the beta cycle, patches are posted to SF just to store them there until after the release of Python 2.3. In the specific case, ask yourself what the cost would be if you produce a test failure under conditions that you consider obscure. Will enough people test the test before 2.3 is released? Does the new test suite behave differently enough from the old one to make false positives a possibility? Regards, Martin
The policy about beta releases is (or should be) stricter. No new features, and perhaps no new tests unless they test for a bug that gets fixed. So in the beta cycle, patches are posted to SF just to store them there until after the release of Python 2.3.
I don't see much of a reason to be so strict about no new tests.
In the specific case, ask yourself what the cost would be if you produce a test failure under conditions that you consider obscure. Will enough people test the test before 2.3 is released? Does the new test suite behave differently enough from the old one to make false positives a possibility?
This is always a good set of questions to ask yourself. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, 2003-04-24 at 18:59, Thomas Wouters wrote:
That's not particularly useful. The only thing that does is create a period in time (or rather, 'history' -- CVS history) in which test_urllib.py doesn't exist. Re-adding the file won't give you a fresh version numbering either, it'll just give you a lot of headaches, especially when there are branches involved (right, Barry ? :-)
And one thing we do /not/ need is more headaches with cvs. :) The specific problem I've been fighting with (in Mailman's cvs) is that I've cvs rm'd some binary files, but both a cvs checkout and a cvs export continue to resurrect the files when I provide -r on the initial command. If I do a checkout of the trunk, then cvs up to the tag, the file goes away as intended. Sigh.
Just commit your new test_urllib.py directly, when it's all done, using something like
cvs commit -r2.0 test_urllib.py
But you probably want to discuss the version number you want to force, Guido might like to reserve 2.0 for something (although I think he should use '3000' instead :)
I know Guido doesn't care, but I like to have the file major revision numbers match the s/w's major rev number. Really, I just hate to see huge minor revision numbers on files. I hate it as much as I hate to hear Tim's tummy rumbling, right around noon. -Barry
[Barry Warsaw]
... I know Guido doesn't care, but I like to have the file major revision numbers match the s/w's major rev number. Really, I just hate to see huge minor revision numbers on files.
Good news: I'm living proof that you can learn to ignore that files *have* CVS revision numbers. If you need a milestone marker, apply a tag.
I hate it as much as I hate to hear Tim's tummy rumbling, right around noon.
Lucky for both of us that my lunch admin almost never lets that happen anymore. If I could remember his name, I'd recommend him to you.
I know Guido doesn't care, but I like to have the file major revision numbers match the s/w's major rev number. Really, I just hate to see huge minor revision numbers on files.
Well, some files already have a 2.x revno, others don't. The 2.x revnos were introduced in ancient times. I'm all for switching to 3.x when we're doing Python 3.0, but until then, I see no reason to play with this. --Guido van Rossum (home page: http://www.python.org/~guido/)
On 24 April 2003, Barry Warsaw said:
I know Guido doesn't care, but I like to have the file major revision numbers match the s/w's major rev number.
Blecchh! Evil! Wrong! Bad! Naughty, naughty! Software versions have nothing to do with file revisions. Some obscure little file might change very little (or not at all) in going from MyGreatBigProduct 1.4 to 2.0. It's revision number should not be artificially bumped just because a lot of other files in the same project got bumped too.
Really, I just hate to see huge minor revision numbers on files.
Then you'll just love Subversion: when Neil S. converted the MEMS
Exchange CVS repository to Subversion back in January, all of a sudden
every file we knew and loved had a revision number around 21000. Yow!
I'm not convinced Subversion's model is exactly right, but it's
certainly no worse than CVS'. Probably better.
Greg
--
Greg Ward
I am rewriting test_urllib.py from scratch since the current version is very lacking (and out of date; the thing tests against UserDict from odd reason). Since I have written it from scratch I figure doing a ``cvs remove`` on the current test_urllib.py and then adding my new version to get a fresh version numbering?
No, just copy it on top. and check it in. We don't do fresh version numbering. :-)
Also, my rewrite is not finished (have some more things I want to test), but what I have so far passes and seems good. Should I bother to check in what I have so far to have it in b1, or hold off until the suite is completely finished? I am assuming since these are unit tests that are passing I don't need to bother with an SF patch to get a code review from someone.
I'd say check it in and keep working on it. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (8)
-
Barry Warsaw -
Brett Cannon -
Greg Ward -
Guido van Rossum -
martin＠v.loewis.de -
Thomas Wouters -
Tim Peters -
Tim Peters