Approaches to forking code

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

--
Chris Velevitch
Manager - Adobe Platform Users Group, Sydney
m: 0415 469 095
www.apugs.org.au
Adobe Platform Users Group, Sydney
Feb '09 meeting: TBA
Date: Mon 23rd Feb January 6pm for 6:30 start
Details and RSVP coming soon
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1036816
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].