On Apr 14 2006, Adam Tenderholt wrote:
>> (2) It'd be good if you could run testall.py before uploading svn
>> changes as this guarantees that code doesn't break, and that we move in
>> the direction of passing increasing numbers of tests (a bug in the
>> latest revision means that all tests failed for adfparser). And I think
>> it's a pretty neat way of comparing the results from different programs
>> for some sort of parser validation.
>
>In the case of my most recent commit, I think you're right. It was a
>silly bug for the gopt case that I hadn't considered. However, I feel
>this isn't practical sometimes. What if I start work on a file, take a
>few days off before getting it to pass the tests, and then you begin
>working on something I had already started? We'd be duplicating our
>efforts. This may be a good thing because you might have the better
>solution, but may also be a waste of time. Also, what if we start work
>on one computer (work) and then finish it on another computer (home)?
>It's easy to hunt down the changed files and copy them as needed, but
>it's not as trivial as just updating your working copy.
>
>I know these two scenarios are rather unlikely and/or the "hard" fix
>outside of svn is actually quite easy, but I think they should at least
>be mentioned. If you think we should just ignore them, that's fine.
>Otherwise, I have two suggestions:
>
>1) Create unstable branches for those few times when we're going to
>start working on a file, but we can't get it to pass the unit tests
>before we take a few day break. This would be as simple as svn copy to
>create new branch, switch to that branch, and then make changes. After
>work is finished, it can be merged (hopefully automatically) back into
>the main branch.
>
>2) Run the tests before a commit, and if anything breaks, say which part
> in the commit log so it's not a complete surprise to other devs. We'll
>be able to review the changes that caused the break, and revert or fix
>them as necessary.
>
>What do you think?
In fact (and I've been thinking about this question and your response over
the past few days, as well as reading the SVN book) I'd like to use a
variation of 1. Since you usually don't know in advance that the tests will
break just before it's time to leave work/go to bed, etc., it's not too
difficult to create a new branch in-place and commit your changes to it.
a) Run the tests before commiting b) If tests that previously passed now no
longer do (when we have a more complete and stable release, this will read
"If any tests fail"), and you don't have time to fix things before
commiting, commits your changes to a new branch as follows:
1) svn copy https://svn.sourceforge.net/svnroot/cclib/trunk
https://svn/sourceforge/net/svnroot/cclib/branches/brokenadfparser
-m "Informative log message about why you're branching"
2) change directory into the 'top' of your working copy where setup.py is
3) svn switch
https://svn.sourceforge.net/svnroot/cclib/branches/brokenadfparser
(note that this preserves the local modifications, only now these
modifications are to the branch instead of the trunk)
4) svn commit (commits the local modifications to the branch)
As soon as the tests that previously passed are passed again, merge the
changes and remove the branch (should be within a revision or two of the
branch).
1) svn log --stop-on-copy (to find the revision when the branching took
place)
2) svn switch https://...../mytrunk
3) svn merge --dry-run -r123:HEAD https://..../mybranch
4) svn merge -r123:HEAD https://..../mybranch
5) svn commit -m "Merging 123:HEAD of mybranch into trunk"
6) svn remove https://..../mybranch
(BTW, I've never tried these instructions, so I'll put them on the wiki and
we can edit them into correctness when we actually try them out)
I'd really like to do this. Of course, it won't always be possible but I
think it's good to have a policy like this. It means that our code is
always improving, and means that test failures are real, and need to be
addressed. Of course, it's a bit of overkill for two developers, but hey
:-) Also, I used to be scared of branches with CVS, but with SVN it's a lot
simpler, so it'd be good to have some experience messing around with them.
I should say that at the same time I wouldn't like to have long- or even
medium-term branches for cclib. I think it'd be good to merge and remove a
branch as soon as the code's not broken.
What do you think of all this? I don't want branching policies to get in
the way of development.
Regards,
Noel
|
