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

Re: Would branching across repositories be theoretically possible?

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 1 Jan 2013 15:38:50 +0100

On Tue, Jan 1, 2013 at 3:23 AM, Ben Reser <ben_at_reser.org> wrote:

There are a couple things to remember here:
> * Subversion was never intended to really break new ground when it
> was designed.
> * The other major Open Source version control systems are all
> distributed (which by its very nature supports this well).
> Despite our history I don't think we can really continue giving
> answers like this. We obviously realize that this sort of workflow is
> important since we mention in the book and point out the vendor branch
> workflow. As has been already pointed out well in this thread we
> don't need to be distributed to support this.

+1. I think it is easy to confuse two independent concepts here:

* SVN _choses_ to be and to remain a centralized system.
  I.e. there is a single, managed _repository_ that defines what
  is part of a given project and who has access to it. Everything
  outside that repo (working copies, mirrors etc.) is, by our
  definition, not part of that project and, therefore, unmanaged.

* SVN wants to foster distributed and disconnected _development_.
  Our working copy concept is living proof of that. Everything that
  improves this is welcome.

OTOH, as long as we stick to the first point, the implementation
of foreign branches and merges will not be too unlike vendor
branches: changes from some outside source will be applied to
your project without creating any hard links to the source. Also
see below.

I think it's time that we took a serious look at making branch and
> merging between repositories relatively easy.


Long Time Ago (TM), I wrote a script that allowed me to work
against a temporary repo for a while and then replicate those
changes in the original repo. So, that use case is relevant and
there is no technical reason preventing us form supporting that
workflow directly in SVN.

IMHO, the workflow should mimic the following behavior:

* Creating a foreign branch via svn cp.
  This can be done today by svn export && svn import. It would
  be very nice if svn cp could skip the data transfer for nodes
  with the same SHA1 as some existing node in the target repo.
  That would be useful for people that create multiple branches
  and / or reuse an existing temp. repo.

* Replay changes from temp. repo.
  Since svn cp used a single source revision, it is easy to
  create a temporary branch in the original repo from that state
  and to replay the foreign changes there. This creates a nice
  audit trail / review opportunity and is in itself a pretty simple
  operation (our replay API might already cover most of it).
  Due to the inner workings of FSFS, the size overhead is
  moderate compared to applying everything in a single commit.

* Merge.
  This would be standard merging in the original repo. A client
  may offer to switch working copies and to trigger the merge
  immediately after the replay finished. So it would become a
  single operation in eye of the user.


* Switch relocate becomes an important operation in that scenario.
  Make sure, there are very few pitfalls.
* Switch relocate should be fast since the SHA1 matches for
  most nodes.
* Selective replay may not be supported. Maybe, we shouldn't
  even try. Let the merge step be the part that optionally reduces
  the change set.
* Consecutive replays should be supported. Use the same temp.
  branch for the replay.
* A temp branch may not be required if the original copy source
  has not been modified since.
* The usual branching / switching / merging granularity concerns
  for ordinary branches apply to foreign branches as well.

Just my 0.02

-- Stefan^2.

Certified & Supported Apache Subversion Downloads:
Received on 2013-01-01 15:39:27 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.