Hi,
I've read several threads on "branching strategy" that I found _very_
interesting.
Here are some situations I would like your feedback on :
1/ One project - one customer
-----------------------------
I know subversion for personal projects. Among those, We (three
developers) are developping a web site. For this situation "One project"
(the web site) - "one customer" (us! considered as a whole team
agreeing on what to do on this web site), our svn tree is :
- trunk/
- src
- scripts
- docs
- branches
- dev_peter_working_on_feature1
- dev_oliver_working_on_feature2
- ...
- tags
- release-1.0
- release-1.1
- ...
Our development strategy is the one called "The Branch-When-Needed
system" in Subversion Best Practices [see
http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html],
i.e minor changes are commited directly to the trunk, larger "feature"
changes are commited to branches and after test, merged back to the
trunk. And at some point of development, we create a tag.
This strategy definitly fits our needs, the process is well established.
2/ One project - several customers
----------------------------------
Context :
---------
Now I have to set this at work. The constraints are different : We often
start a project which is supposed to be "standard" for all customers.
But, as usual, at some point of development, a customer wants a
completely different behaviour of our application for a specific
situation, we could say a specific "feature"
Solution with Clearcase :
-------------------------
I used Clearcase in a global company and this type of "problem" (or
customer request ;-) ) was easy to face : Clearcase provides different
"views" of our code (using a config specs, see this message to quickly
understand this notion :
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=65371)
So we branched some specific files to implement the different
application behaviour for ourcustomer.
Then, managing customer versions was easy since we just had to have
different config specs, one for each.
Thanks to clearcase, modifying common code is automatically reported
into each customer code.
Solution with Subversion ? :
----------------------------
But Clearcase is now an old story for me and my new company is going to
switch from VSS to SVN.
I've considered the following solution : When the new "customer
behaviour change" arrives (cf [1]), create 2 branches, one for the
standard, the other for the customer specific :
[1] [2]
-----trunk----------------------------------------
| |
------ standard dev branche -------
| |
------ customer dev branche -------
Then developper still commit in the trunk using the "The
Branch-When-Needed system" startegy. And the integrator has then to
regularly merge trunk to standard dev and customer dev branches [2]. The
main problem I can see is that integrator has to be sure that a merge
from trunk won't affect the specific fonctionality of customer dev
branche.... and it is not so easy (and with growing code, may be
unfeasible ?) !
You could say "use external links" to separate common code from customer
specific code. That is not possible. Sometimes the customer specific
code resides on one line of a file !
An other approach is to embed specific customer behaviour into code
using (I take C code for example) preprocessor macros. I've survived
with this awfull solution but definitly don't want to retry it !
so, finally, my question is quite simple (answers may not) : how can I
manage such a situation using a robust software development process
based of this subversion marvelous tool ?
Thanks a lot for your comments !
Pierre
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 15 10:56:10 2007