Approaches to forking code

[Chris Velevitch <ch...@gmail.com>]

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@subversion.tigris.org].

Re: Approaches to forking code

[Les Mikesell <le...@gmail.com>]

Chris Velevitch wrote:
> 
> 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?

If staying in the same repository is a possibility, it is not a fork in 
the usual sense and you might as well use a branch that is just never 
merged with the trunk.   Or, if existing code is going to be developed 
into a different program, perhaps you should refactor anything that can 
continue to be shared into libraries.

> 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.

In a real fork, there would probably be new management starting from 
scratch deciding what version control package to use.  So, you'd be 
looking at the conversion tools, or if you stick with subversion it 
would be an svnadmin dump, perhaps followed by filtering other projects 
out, then loading into a new repository.

-- 
   Les Mikesell
    lesmikesell@gmail.com

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1036861

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Approaches to forking code

[Trevor Harmon <tr...@vocaro.com>]

On Jan 20, 2009, at 10:15 AM, Bob Archer wrote:

> Isn't a fork really just a another name for a branch?

That's what I thought as well. Going by Wikipedia, however, it would  
seem that a branch is internal to a repository, while a fork would  
only happen when a version of the code moves outside the repository.  
See: http://en.wikipedia.org/wiki/Fork_(software_development)

On the other hand, Chris indicated that a fork might occur within a  
single repository, so I'm confused. Chris, what exactly is the  
difference, in your mind, between a branch and a fork? It's difficult  
to talk about these things without a common definition.

Trevor

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1045581

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

RE: Approaches to forking code

[Bob Archer <Bo...@amsi.com>]

> 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

Isn't a fork really just a another name for a branch? I think using svn
cp URL URL is the best solution for this. I think the main difference
between a banch and a fork is perhaps where you copy to in your repo. 

For example... you might do this to branch:

Svn cp http://server/repo/project/trunk
http://server/rept/project/branches/branchname

Where as to fork (create a new project based on current project) you
might do:

Svn cp http://server/repo/project/trunk
http://server/repo/NEWproject/trunk --parents

Now in your repo you have:

Project
 -trunk
 -tags
 -branhes
Newproject
 -trunk

BOb

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1038095

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

Re: Approaches to forking code

[Matthew Pounsett <ma...@conundrum.com>]

On 20-Jan-2009, at 00:20 , Chris Velevitch wrote:

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

In my mind the only distinctions between branching and forking are:

1) An entirely separate organization of people will be maintaining the  
new code
and/or
2) The new code is not expected to retain any similarity to the old  
code base

If your use case doesn't match one of those conditions then it's just  
a new branch, and I'd recommend you do a cheap copy in the same  
repository.

I think the above is only likely to occur in a few sets of somewhat  
rare circumstances.. such as a group deciding they don't like the  
direction an open source project is taking, wanting to fork off their  
own project and take it a different way ... or a corporation licensing  
another company to repackage or adapt some software.

Matt

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1036837

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].