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

Re: Approaches to forking code

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 20 Jan 2009 00:23:40 -0600

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
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-20 07:24:33 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.