aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes best way to check that branches stay in synch? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "best way to check that branches stay in synch?" Watch "best way to check that branches stay in synch?" New topic
Author

best way to check that branches stay in synch?

Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42600
    
  65
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 ]

Ping & DNS - my free Android networking tools app
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
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.



Spritle Software Blogs
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42600
    
  65
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 ]
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30919
    
158

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Marshal

Joined: Mar 22, 2005
Posts: 42600
    
  65
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.
David O'Meara
Rancher

Joined: Mar 06, 2001
Posts: 13459

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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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).
Aruneesh Salhotra
Ranch Hand

Joined: May 12, 2004
Posts: 167
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
Marshal

Joined: Mar 22, 2005
Posts: 42600
    
  65
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: best way to check that branches stay in synch?