On Tue, Jan 1, 2013 at 3:23 AM, Ben Reser <b...@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 *
