• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

best way to check that branches stay in synch?

 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everyone-

We're about to branch the main source trunk for a huge side project. Eventually (after release) the branch will become the trunk again, but in the meantime, there will be fixes and additions to the trunk as well. To make it easier on us later, we want to add all those trunk changes to the branch as well. But the project involves thousands of files and around a dozen developers - someone is bound to forget to check in something.

So I'm thinking about a tool that checks (perhaps on a nightly basis) that every change to the trunk is applied to the branch as well. I might settle for something that tells me "developer A has checked in file B on date C in the trunk, but he didn't in the branch". That would allow me to remind the developer. If the tool tells me in addition to that: "well, he changed the trunk file in 3 locations, but the branch location in only 2", that would be even better.

Are there tools that do this? Or alternatively, is there a decent Java library to access CVS, on top of which this could be implemented? We're using Ant, CruiseControl and CVS. I'm looking for approaches as much as for actual tools and libraries.

Thanks in advance for insight you can offer.
[ January 16, 2006: Message edited by: Ulf Dittmer ]
 
author and deputy
Posts: 3150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i know this is a dump reply, but you could ask someone in apache fop dev group, because if you look at the fop source download structure, its looks somewhat simillar to waht you are talking about...like Old maintainance branch, new, trunk.

 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Shouldn't the VCS tell you exactly this?

That is, shouldn't you be able to simply say to the VCS "merge all the changes made on the branch since the last merge to the trunk"?

What VCS are you using?
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja said:

Shouldn't the VCS tell you exactly this?



We're using CVS (with WinCVS and TortoiseSVN clients). I don't know that it does any kind of reporting of this kind, which is why I thought of rolling my own. I'd be glad if it does so reliably, because I'd much rather work with the tools that are already in place.

Or are you suggesting letting CVS do the merge - I guess the question then is: do people here actually do this for maintaining branches on a regular basis? Run "merge" in the CVS, check all locations the CVS flags as "can't-reconcile-on-my-own" and fix by hand, and commit the merged files to the branch? Wouldn't this become more and more laborious as the branch deviates from the trunk?
I always had the impression that CVS doesn't like having files copied to its checkout directory so that you can run a diff or merge - it usually complains about files not being up-to-date, and then refuses to commit the merges. Or maybe that's just because I don't know the ins and outs of CVS well enough.
[ January 16, 2006: Message edited by: Ulf Dittmer ]
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If all else fails, you could use the cvs history command against the trunk and make sure all of those files were updated in the branch (through another cvs history command against the branch.) This could all be scripted in something the Ant build calls.

How often do you have check-ins? If they are rare, you could use cvs mail and make sure they come in pairs. If they are frequent, this would be too overwhelming.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ulf Dittmer:
Wouldn't this become more and more laborious as the branch deviates from the trunk?



Yes, but so would any other system, right? As the branches diverge, then figuring out how to apply a patch from one to the other gets harder and harder. Once you start to have a lot of file splits/creates/deletes, then reconciling the changes becomes pretty much impossible for an automated system.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ulf Dittmer:
Or are you suggesting letting CVS do the merge



Yes, exactly.

I guess the question then is: do people here actually do this for maintaining branches on a regular basis?



Yes. I wouldn't know why else you would want to branch...


Run "merge" in the CVS, check all locations the CVS flags as "can't-reconcile-on-my-own" and fix by hand, and commit the merged files to the branch? Wouldn't this become more and more laborious as the branch deviates from the trunk?



Yes, but as Ernest already pointed out, that's not specific to using the automated merge feature. Manually porting fixes between branches will also become more and more laborious over time.

The trick is to only have (relatively) short living branches.

I always had the impression that CVS doesn't like having files copied to its checkout directory so that you can run a diff or merge - it usually complains about files not being up-to-date, and then refuses to commit the merges. Or maybe that's just because I don't know the ins and outs of CVS well enough.



Sorry, I have no idea what you are talking about, just the diffuse feeling that you might not use CVS the way it is supposed to be used.

What files are you copying to where for what reason?

And, what is your motivation for branching?

 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BTW, most problems we encounter with merging branches have more to do with files being renamed or moved. There are VCS systems that handle that better than CVS (for example subversion).
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://tinyurl.com/byn62 probably gives a good impression on how we use CVS branches.

The repository branch on the lower half, with the long delayed merge, sounds a little bit like what you are planning to do - with the difference that there was a lot of development on the trunk (HEAD), too, resulting in a merge disaster (it took three days to merge, if I remember correctly).

In that case, it would have been better to not work on a branch, but to make it a configuration option of the system under development to include the changes or work the old way, in my opinion.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Balaji Loganathan:
its looks somewhat simillar to what you are talking about...like Old maintainance branch, new, trunk.



It is similar, but the FOP branches will never be reconciled - they're different to the point where a patch to the branch probably doesn't even apply to the trunk.
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In comparison our team is currently 5, but has grown to 8 or so. The code base is several thousand classes, stored in CVS (on a Linux server) and we use a mixture of TortoiseCVS and Eclipse as clients, mostly through Eclipse though.

We have a constant maintenance/bug fix/minor enhancement stream working on a main branch, and we always create a separate branch for major work orders and merge it back (Using Eclipse) once completed. If the work order takes a long time we sometimes merge from maintenance into the project branch so that they don't diverge too much.

The only real issue (besides the deletion/rename/move already mentioned) was the CVS tage, $Log$, Author etc. They were a nightmare and we eventually had to scrap them all. If you use them they are wonderful when used in a single branch, but they tend to snowball out of control when used between multiple branches.
[ January 17, 2006: Message edited by: David O'Meara ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David O'Meara:
In comparison our team is currently 5, but has grown to 8 or so. The code base is several thousand classes, stored in CVS (on a Linux server) and we use a mixture of TortoiseCVS and Eclipse as clients, mostly through Eclipse though.



Very similar here: 5 developers, shortly growing to 7, over a million lines of code in 80+ cvs modules, Eclipse as the main client.

We have a constant maintenance/bug fix/minor enhancement stream working on a main branch, and we always create a separate branch for major work orders and merge it back (Using Eclipse) once completed.



We work the other way around: major development on the main branch, a branch for minor bugfixes. The bugfixes are regularly merged into the main branch. I'd expect that this would reduce the merge problems, simply because the number of changes that need to be merged is lower.

The only real issue (besides the deletion/rename/move already mentioned) was the CVS tage, $Log$, Author etc. They were a nightmare and we eventually had to scrap them all. If you use them they are wonderful when used in a single branch, but they tend to snowball out of control when used between multiple branches.



Yes, we scraped them, too. I don't even think they are wonderful - they bloat the source code without giving much information you couldn't extract on the fly (minus renames and moves, if you use CVS, of course).
 
Ranch Hand
Posts: 167
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All this can be accomplished fairly easily, using ANT. You can call ANT through say PERL, and parse the "cvs log" for diffs of DIR in HEAD and branch.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the replies, everyone. It looks like CVS on its own can accomplish what we need to be done, and that people use it successfully for that. I guess we need to review how our client and out team use the shared CVS in order to use it to its fullest.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic