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

Using subversion (or something else?)

From: Gary . <subversion-users_at_garydjones.name>
Date: Fri, 21 May 2010 11:32:40 +0200

I am trying to decide, or at least get information to help me
decide, whether subversion or "something else" would be suitable
for us. Let me explain the situation. We use a product which we
customise and add features to, both of which mean changing the
source. Sometimes these changes also get accepted by the vendor
and are included in the next release. So when we get a new
release we get a new bundle of source files and so forth (in some
format which I don't know offhand, but probably isn't important
to this anyway), and we then have to manually merge the changes
we have made to the last version into the new version, some of
which might be changes we already have.

I think one way of thinking about it is that our changes are a
series of patches, some of which are accepted upstream and some
not (this is what makes me wonder whether something other than
subversion might be better for us, but that might be just my
brain making a connection between the word "patch" and systems
that I know use this kind of patching concept, such as
darcs). Maybe there is an alternative way of thinking about the
situation which means that subversion, which I am more at home
with, would be suited.

So the first question is, do you think subversion is suitable in
this case, and if not is there something "better" (in the sense
it will be easier for us to use) that you can recommend?

So the first question is, do you think subversion is suitable in
this case, and if not is there something "better" (in the sense
it will be easier for us to use) that you can recommend?

Secondly, if subversion is suitable, what's the best way to use
it in this situation (regarding branching, releasing, etc.)? I
worked somewhere with this kind of situation before (changing and
customising vendor code, with new vendor releases being
introduced from time to time), and we basically used branches for
each new vendor, and internal, release. Where I am now, we have a
very short internal release cycle, along the lines of "code it,
ship it!" (we effectively work directly on the live system, which
I am not in favour of, but we do need that quick turnaround from
code-change to production system). At the other place we had a
script that did a lot of the merging between the production
branch, where bug fixes would be implemented, and the "new
features" branch where we would be working. Obviously I don't
have that script now, but is there anything around that can do
that kind of merging, if I managed to convince people to adopt
that kind of way or working? Or is there some better way of
working in this situation? Okay, so "better" is somewhat
subjective, but I am open to ideas so don't be afraid to throw
them into the middle.

Thanks in advance for your suggestions.
Received on 2010-05-21 11:33:18 CEST

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.