Commit laziness when dealing with multiple branches

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Commit laziness when dealing with multiple branches

Post by Ambush Commander »

I've discovered the greatness of laziness in handling commits when you have to maintain multiple branches. Any documentation tweak, etc ends up having to be ported to at least one earlier branch, which can be a somewhat painful process.

This doesn't feel right.

For example: I recieved a potential bug-report for this project. I banged out a quick test-case to verify and was unable to reproduce, so I simply reverted my working copy. Now, obviously, something hadn't been covered otherwise I wouldn't have created the test-case, but since it was a pass, I didn't bother saving it. Perhaps I should have: more comprehensive.

Opinions? Also related: how in-depth are your test-cases?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

I keep bug reports as separated tests.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Well, valid bug reports of course (although I wouldn't go as far to say seperate file for each). But this is something that I can't reproduce (yet), probably once the reporter gives more information I'll understand it better.

Not sure how it ties in to the original problem.
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

Do you use a bug tracker? i usually create a ticket and verify it with unit or functional tests, if it passes, then closed the ticket as invalid. e.g. say the ticket number was 123, then i create a test class name Ticket123TestCase and stick them in the ticket test directory. Thus, each ticket must be covered by at least 1 test case, you never know, sometimes these tickets become valid later on.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Depends on the report - if the reporter seems fairly knowledgeable and I did write a test case to attempt replication, then I'd likely keep it around...especially if the test case seems to check something I view as a possibility. Better safe than sorry afterall. The bug could be server specific to the relevant PHP/Postgres/etc. version the guy was then using.

I'd say if the test did not harm anything else then leaving it in does no harm, and leaving it out robs you of a potential early alert to a valid problem in the future.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Do you use a bug tracker? i usually create a ticket and verify it with unit or functional tests, if it passes, then closed the ticket as invalid. e.g. say the ticket number was 123, then i create a test class name Ticket123TestCase and stick them in the ticket test directory. Thus, each ticket must be covered by at least 1 test case, you never know, sometimes these tickets become valid later on.
Yes, I do use a bugtracker, however, I got the bug report from a different channel, so there's no bug report to attach it too. I've asked for clarification, because my test-case probably was bad.

Really, I suppose I should keep all the test-cases I can. But the point of the matter is that it's painful to add even two lines when there are two branches running in parallel. Anyone have a solution for these woes?
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

how are the branches related? are you able to merge the differences from, say, branch A into branch B? it is much easier if the merge is in one direction only.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I am using merges. My current workflow is this:

1. Load up the log for trunk/ and identify mergeable changes
2. Switch working copy to branch
3. Perform merges (may be more than one)
4. Commit, amalgating all the logs from those other changes into this one
5. Switch working copy to trunk
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

i assume that your trunk is the lastest and greatest ;), it seems that you are working on the trunk and then merging them into the branches. how about working on branches and merge into trunk, thus the trunk will be a collection of branches with all the test suites. And when ever you want to take parts of the trunk, create a new branch. So the trunk is the central place with all the code from all branches. This may not work if your branches are not inter-related, but then you don't need the tests for the not related code.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Nope. The branches are just a convenient place to freeze feature development and concentrate on bug fixes. Extra features makes squashing bugs a bigger headache, personally speaking.
Post Reply