[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Best practices for managing chaos?

From: Clay Loveless <lists_at_crawlspace.com>
Date: 2004-05-20 00:41:06 CEST

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

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

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,

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 20 00:41:56 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.