• 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

Refactoring Mercilessly in separate branches

 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...
 
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 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?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...).
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?"
 
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 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.
 
Alas, poor Yorick, he knew this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic