Too Many Cooks!

[Clay Loveless <li...@crawlspace.com>]

I'm groping about for a guideline on how to best deal with situations where
not all developers who touch a particular project use Subversion.

Here's a scenario:

1. Company XYZ installs Buggy Freebie Script 1.0, managed by Joe Blow with a
private CVS repository.

2. Someone at Company XYZ hacks around with BFS 1.0, uses no version control
tools.

3. Company XYZ hires Stan the Man to extend BFS 1.0 features to meet Company
XYZ's custom requirements. Stan the Man doesn't use version control either.

4. Joe Blow releases BFS 1.1.

5. Right around here, Company XYZ hires me to debug Stan the Man's crappy
work, and upgrade their hacked BFS 1.0 to BFS 1.1 without losing their
hacks.


Variations of this scenario play out for me all the time. I'm trying to
determine the best way for me to remain sane in this type of environment.

Obviously, I need to use the vendor branches techniques described in the SVN
book ... But, since there are so many cooks in the kitchen here, the vendor
branches method doesn't cover it all for me.

Or does it ... And I just need to have vendor directories/branches for each
cook that I continue to merge back into the trunk?

Has anyone else who deals with this kind of chaos come up with a good way to
manage it somewhat effectively?

Thanks in advance,
-Clay 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Too Many Cooks!

[Wesley J Landaker <wj...@icecavern.net>]

On Wednesday 19 May 2004 4:57 am, Clay Loveless wrote:
> I'm groping about for a guideline on how to best deal with situations
> where not all developers who touch a particular project use
> Subversion.

I run into issues like this pretty often, where I'm the only one that 
uses version control. Here's how I'd handle it, which may or may not 
actually be the best way to do it (so I'm interested in ideas from 
others too!)

> Here's a scenario:

> 1. Company XYZ installs Buggy Freebie Script 1.0, managed by Joe Blow
> with a private CVS repository.

Well, here is a starting point. I go by the book and make:

trunk/
tag/
branch/
vendor/
  bfs-1.0
  current

Where bfs-1.0 is just a copy of current, which was imported from the 
fresh bfs upstream source.

> 2. Someone at Company XYZ hacks around with BFS 1.0, uses no version
> control tools.

Assuming you don't have this intermediate version, we can't do anything 
with it yet...

> 3. Company XYZ hires Stan the Man to extend BFS 1.0 features to meet
> Company XYZ's custom requirements. Stan the Man doesn't use version
> control either.

So now you have a hacked-up version of 1.0 that isn't going to have 
further development (because they fired Stan the Man (or promoted him 
to management) when they hired you).

Since it's static, I throw it in as a tag, say tag/STM-hacks. If he was 
going to keep working on it and you had to keep merging his changes for 
all eternity, I'd put it somewhere like, say, vendor/branch/STM, and 
that would of course complicate things somewhat.

Now, this is also the current version that is in use, so I copy it to 
the trunk. Now I have:

trunk/  -- currently the same as tag/STM-hacks
tag/
  STM-hacks
branch/
vendor/
  bfs-1.0
  current  -- currently the same as bfs-1.0

> 4. Joe Blow releases BFS 1.1.

So I update vendor/current from the upstream code using svn_load_dirs, 
or by doing it manually if it's simple. I copy that to vendor/bfs-1.1, 
so now:

trunk/  -- currently the same as tag/STM-hacks
tag/
  STM-hacks
branch/
vendor/
  bfs-1.0
  bfs-1.1
  current  -- currently the same as bfs-1.1

> 5. Right around here, Company XYZ hires me to debug Stan the Man's
> crappy work, and upgrade their hacked BFS 1.0 to BFS 1.1 without
> losing their hacks.

Now I need to merge the changes from bfs-1.0 to bfs-1.1 into the trunk, 
so we do a svn merge between bfs-1.0 and bfs-1.1 into the trunk.

Now it's just a matter of manually resolving conflicts, which is going 
to be either easy or hard depending on how much common code was changed 
in divergent ways from bfs-1.0 between STM-hacks and bfs-1.1

Once it's done, I commit to the trunk, tag it as bfs-1.1+xyz-1.0 and 
wait until the next barrage of changes comes in from whatever source. 
=)

> Obviously, I need to use the vendor branches techniques described in
> the SVN book ... But, since there are so many cooks in the kitchen
> here, the vendor branches method doesn't cover it all for me.
>
> Or does it ... And I just need to have vendor directories/branches
> for each cook that I continue to merge back into the trunk?

If you have several sources that keep making changes, I usually make my 
vendor tree have a subdirectory for each "source" that could be making 
changes. If two sources make changes and send them to me at the same 
time, I just apply them one at a time.

vendor/
  source1/
    version-2
    version-1
    current
  source2/
    version-3
    version-2
    version-1
    current

> Has anyone else who deals with this kind of chaos come up with a good
> way to manage it somewhat effectively?

As I said, I deal with this all the time, so I end up being *very* 
liberal with tags and branches. If the merge step ends up looking like 
it's going to be overwhelming, I'll try to break it down into a series 
of tasks (merge new-feature1, merge bugfix-xyz, etc) and apply them 
each separately (branching for each task if necessary).

It's always:
1. Get sources from others
2. Do magic with version control
3. Manually merge/resolve
4. PROFIT!!!

The hard part is always the manual merge/resolve step, but other than 
just attacking it methodically and intelligently I'm not sure how to 
avoid it, but learning how to do #2 in better ways has made it more fun 
and less painful. =)

-- 
Wesley J. Landaker <wj...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2