Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Date: Tue, 11 Jan 2011 20:16:09 +0100
From: Stefan Sperling <stsp@elego.de>
To: NN Ott <nonot100@gmail.com>
Cc: Ryan Schmidt <subversion-2011a@ryandesign.com>,
        users@subversion.apache.org
Subject: Re: Feature Request: [Was: Best way to maintain patches to a 3rd
 party library?]
Message-ID: <20110111191608.GC20710@ted.stsp.name>
Mail-Followup-To: NN Ott <nonot100@gmail.com>,
	Ryan Schmidt <subversion-2011a@ryandesign.com>,
	users@subversion.apache.org
References: <AANLkTi=g18Z+_N6vb7z_38xW8LSnqMiOrmNh_4gaQ-5K@mail.gmail.com>
 <20110111180200.GB20710@ted.stsp.name>
 <AANLkTimFBn-4Y9pRzeF7WLjk9MupZRtn4dJoaPxe6ThB@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTimFBn-4Y9pRzeF7WLjk9MupZRtn4dJoaPxe6ThB@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Tue, Jan 11, 2011 at 01:36:37PM -0500, NN Ott wrote:
> I just want the svn copy/log/diff/merge logic to see past, and account for,
> and svn:external barrier.   Very much a one-way flow of changes.  Imho,
> doesn't seem too bizzare or non-svn like.

It may seem like that on the surface.

But an external is a nested checkout within another working copy.
That's all there is to it. It is bound to the repository it came from.

Creating diffs between two distinct Subversion repositories, for
instance, is impossible to achieve with the current design of Subversion.
If you try it, you get an error like this:
svn: 'https://svn.example.com/repos1/README' isn't in the same repository
  as 'https://svn.example.com/repos2/README'

Making this work would require redesign of the system.
It's not an implementation bug that this doesn't work.
It's something the design doesn't support, because Subversion is centralized.

If you want to reason and argue about this you will need to understand
technical details of the current design. So I'd suggest that you familiarize
yourself with Subversion's design, and then rephrase your proposal in a
way that explains how Subversion's current design would need to be
changed in order to achieve what you want.

Unfortunately it's not easy to summarize everything you need to know
in one email.

You'll need to understand how the repository filesystem works.
A fairly good explanation is given here:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history

A good overview of how the client/server communication is currently
structured is given here:
http://www.red-bean.com/kfogel/beautiful-code/bc-chapter-02.html
While linking to the above, it should also be noted that there is a new,
currently unused, interface trying to address various shortcomings:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_editor.h

Stefan