Re: Too Many Cooks!

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 <wjl@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2