aspose file tools*
The moose likes Agile and Other Processes and the fly likes Refactoring Mercilessly in separate branches Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Refactoring Mercilessly in separate branches" Watch "Refactoring Mercilessly in separate branches" New topic
Author

Refactoring Mercilessly in separate branches

Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I woke up this morning with a question in mind (don't ask me why, my mind works in mysterious ways ) so here it goes...
When doing XP in a project where several teams work on a mutual code base, at some point a team probably needs to touch the same code as another team.
Assume a version control system is in use and each team, working on their respective features, are using branches to do their thing.
So, the question is how does Merciless Refactoring mix with branch merging? My initial reaction to this thought was "God, please don't let it be me who has to merge the two branches" as I definitely wouldn't be able to rely on automerging features provided by ClearCase and other top-notch CM systems.
Isn't it (theoretically) pure hell to merge changes into a file where both branches to be merged have refactored the original codebase mercilessly?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Assume ... each team, working on their respective features, are using branches to do their thing.
This is where the problem lies, in my experience. To make use of merciless refactoring you really need to be running the complete unit test suite and comitting changes every few minutes.
Can you explain a little more about why you feel that working on branches is something so obvious that you can assume it for a problem like this?
To me, branching is like those little hammers for breaking windows you sometimes find by fire alarms - A great way of getting out of a burning building, but hardly something I'd use every day.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Frank Carver:
To make use of merciless refactoring you really need to be running the complete unit test suite and comitting changes every few minutes.

If you're doing Big Refactoring, e.g. adding a separate controller layer (m+v+c) into a document-view design (m+vc), the checkin won't be done within "a few minutes" of the checkout. Anyway, you're absolutely right about that this should be the case almost all the time.
Originally posted by Frank Carver:
Can you explain a little more about why you feel that working on branches is something so obvious that you can assume it for a problem like this?

Well, I've working in a maintenance operation for some time now and there's a process with releases that some times drops parts of the release in the last minute (e.g. because it hasn't passed acceptance testing, is otherwise late, etc). In these cases, it's pretty damn useful to have a single branch to rollback compared to seven versions of a file with seventeen versions from other teams all scrambled up.
Ok. I think this wouldn't be an issue if everybody would be doing continuous integration. Unfortunately we're not. And the ClearCase update takes between 10-15 minutes to complete (it's a BIG project) anyway so I doubt we'll ever manage to achieve too fast pace of integration...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:
If you're doing Big Refactoring, e.g. adding a separate controller layer (m+v+c) into a document-view design (m+vc), the checkin won't be done within "a few minutes" of the checkout.

The art of doing a big refactoring basically is splitting it into several small ones.

Well, I've working in a maintenance operation for some time now and there's a process with releases that some times drops parts of the release in the last minute (e.g. because it hasn't passed acceptance testing, is otherwise late, etc). In these cases, it's pretty damn useful to have a single branch to rollback compared to seven versions of a file with seventeen versions from other teams all scrambled up.

I don't understand why you'd need braches for this - don't you just need tagged "known to be good" versions? Can you please elaborate?
And the ClearCase update takes between 10-15 minutes to complete (it's a BIG project)

Huh, how big is BIG??? Why does it take so long?


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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
I don't understand why you'd need braches for this - don't you just need tagged "known to be good" versions? Can you please elaborate?

Actually, I don't know. I'll have to ask the build manager. It's possible that we're just doing things the wrong way and thus aren't able to do certain things (and what are the reasons to do things wrong if it's intentional).
Oh, "BIG" is 1,5MLOC running on a handful of unix boxes and another handful of NT boxes (with tens of distributed IPlanets around the globe for caching static content). Why the update takes so long? Probably because of the network (the repository is not "next door" and I believe the same repository server is used for many more projects as big as ours...).
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Branches scare the heck out of me. We try real hard to avoid them.
A lot of XP practices came out of Smalltalk tools that let two people work on a class at the same time. The first one checked back in is no problem. On the 2nd one the tool compares them. If they did not modify the same method, it replaces old methods with new ones. If they did, the user might be prompted to manually merge the code. Visual Age tries to do this, too. Other IDEs??
The bad part about branching is you (probably) gotta merge some time. With a lot of refactoring going on there could be way too many changes in both branches to ever figure out.
XP's "no code ownership" or "community code ownership" seems to me to require good tools and ideal configurations. It also helps enormously to have everyone in a room together. "Hey, Bob, what the heck did you do to this thing?"


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Branches scare the heck out of me. We try real hard to avoid them.

Dito!
A lot of XP practices came out of Smalltalk tools that let two people work on a class at the same time. The first one checked back in is no problem. On the 2nd one the tool compares them. If they did not modify the same method, it replaces old methods with new ones. If they did, the user might be prompted to manually merge the code. Visual Age tries to do this, too. Other IDEs??

CVS allows this, too. Eclipse has quite good support for interactive merging.
The bad part about branching is you (probably) gotta merge some time. With a lot of refactoring going on there could be way too many changes in both branches to ever figure out.

Yes - long-lived branches combined with merciless refactoring can get you to hell...
XP's "no code ownership" or "community code ownership"

The latter! That's very important!
seems to me to require good tools and ideal configurations. It also helps enormously to have everyone in a room together. "Hey, Bob, what the heck did you do to this thing?"

Yes. It also helps to have many small classes, as this reduces the probability of conflicts. And the most important practice is probably integrating as often as possible.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Refactoring Mercilessly in separate branches