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.
>
+1.
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.
Observations:
* 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:
*
http://www.wandisco.com/subversion/download
*
Received on 2013-01-01 15:39:27 CET