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

Approaches to forking code

From: Chris Velevitch <chris.velevitch_at_gmail.com>
Date: Tue, 20 Jan 2009 16:20:30 +1100

I see there is a fair amount of information and discussion on
branching, tagging, copying and merging but I see nothing on forking.

I understand that subversion makes no distinction between branching,
tagging and copying, they're all done with the same command: svn copy.
I also understand that copying is not expensive in that they don't
take up extra space. So I can see that forking will also have no real
distinction in subversion because it will also be done with the svn
copy command.

The way I see it, there are 4 approaches to forking code:-

1. Just copy
2. Make expensive copies
3. Create a new repository and import
4. Create a copy of the existing repository

1. Just copying it is straight forward as it keeps the change history
and there's no restriction as to where it goes.
2. Makes expensive copies. That is duplicate the code by exporsting
and importing which breaks the connection to the original code and
looses the history.
3. Create a new repository by exporting from the current repository
and import. This also looses the history.
4. Copy the existing repository which keeps the history.

When you fork code, you need to make 2 decisions: same or different
repositories and keep or loose the history. But what are the factors
that would influence these decisions? Would one consideration be: Will
the forked code base change a little or alot?

Whilst I have yet to fork code (that's going to happen real soon), I
can see the choice of approach to forking will have varying degrees of
impact on a couple of situations that could arise.

When changing and testing some code, you may see or discover that the
original code has a fault. What approach would be used to merge that
fix into the original code base?

There's a bug in the original code base. Depending on the fork
approach, how would that be merged. If the forked file(s) have
changed, that may be straight foward.

There's a bug in the forked code base in file(s) have haven't changed,
but the corresponding file(s) in the original code base have changed.

These are just some of my thinking out loud ideas to help me work out
what my approach will be, but I guess I'm a little surprised that
there's nothing formal around on this topic (unless it's under a
different name) considering that version control and it's principles
have been around for a long time.


Chris Velevitch
Manager - Adobe Platform Users Group, Sydney
m: 0415 469 095
Adobe Platform Users Group, Sydney
Feb '09 meeting: TBA
Date: Mon 23rd Feb January 6pm for 6:30 start
Details and RSVP coming soon
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-20 06:21:24 CET

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.