On 18.08.2005, at 00:26, Michael Wehrle wrote:
> I have been developing a software system for a couple of years now.
> During that time I had to customize certain areas for different
> customers and that resulted in
> me having 5 different "copies" of originally the same software.
> Much of the code of those different "copies" is (or should be) of
> course exactly the same.
> I did the merge of changes to one of the copies to the other by
> using "compare to each other" in Eclipse
> and merge the differences manually.
>
> [snip]
>
> Can someone please help me taking the steps to "import" all these
> various "copies" I currently have into subversion?
>
> How do I create branches from these copies?
> Or canI?
> Do I have to dedicate one copy as the trunk first ?
> Can I actually import the copies into branches?
Ignoring for a moment how to import it, yes, I suppose one option
would be to have /trunk be the "main" version, if there is such a
thing, or maybe, a version that has none of the 5 customers'
customizations -- is a generic version. Then there would be 5
branches, 1 for each customer. You would develop in trunk, then merge
the change to the 5 branches. If a generic non-customized version is
not applicable, then you could consider not having a trunk as such,
and just do development in any of the 5 branches, and then merge the
change to the other 4 branches.
I think that would get annoying though. In our projects at work, we
merely have a trunk and one live branch at a time, and I find even
that annoying. Really wouldn't want to have to merge to 4 or 5 other
branches. It's also fairly easy to do a change in one place and
forget to merge it to the other places, or at least, forget to merge
it to all the other places.
In the project that I have that's used by three different customers,
I took a different approach, and have all three customers' versions
in a single environment. I have all the code conditionalized to
enable or disable certain customers' features at the flick of a
switch, so to speak. When I first check out a working copy, I then
run a script within the working copy which sets up which customer's
environment to use. It just writes the customer's name to a file in a
config directory, and the rest of the project knows to look there to
determine how it should function. I like this because there's no
merging, but if your project is not already written like this, it
would mean rewriting the customer-specific parts somewhat.
Yet another option I've wanted to explore but haven't due to lack of
time is using Subversion externals for this. I would envision having
the generic version in one repository directory, and then having
separate directories for each customer. Um...
/genericsoftware/
trunk/
branches/
tags/
/customer1/
trunk/
branches/
tags/
/customer2/
...
The idea here would be that /customer1/trunk/ would only contain a
directory linked to /genericsoftware/trunk/ plus whatever
configuration files or additional code or graphics are necessary to
customize it for that customer. The generic software would obviously
also have to be rewritten in this case, to know to look for the
configuration files and other files out there. But on paper this also
sounds like a nice idea since there would be no need to merge anything.
Actually you'd probably want to link not to /genericsoftware/trunk/
but rather to a specific branch: /genericsoftware/branches/some-
branch/ or, later in development, to a specific tag. So that you
could say that customer1 will be upgraded to the new version 1.4, but
customer2 will stay on version 1.3 for now.
I suppose it's not so much "generic" but rather "consolidated." So
who knows if that's the brightest idea. Anyway, just some ideas for
you to think about.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 18 02:11:24 2005