You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by NN Ott <no...@gmail.com> on 2011/01/11 18:36:58 UTC
Feature Request: [Was: Best way to maintain patches to a 3rd party library?]
>
>
> >> To recap, as Les put it:
> >>
> >> I think the idea is that he'd like to see the development history of
> both the vendor and local changes as a continuous set of changes as you
> would if they were in the same repository with log and diff working across
> any points in time or branch versions. It seems like a reasonable thing to
> want, but I don't think it is possible with subversion.
> >
> >
>
> I don't think the request can be met by Subversion. Subversion is a
> centralized version control system; the request is met by not using a
> centralized version control system, but instead using a distributed version
> control system.
>
>
>
With the new merge tracking capability being added, I would think this could
be on the horizon as well. A full fledged distributed system hardly is
needed or even what I am looking for.
Has such a feature request already been logged?
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, Jan 11, 2011 at 19:02:00 +0100:
> See here: http://subversion.apache.org/faq.html#multi-merge
This contains a broken link to <http://subversion.apache.org/links.html#misc_utils>.
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by Les Mikesell <le...@gmail.com>.
On 1/11/2011 12:36 PM, NN Ott wrote:
>
>
> It sounds like what you really want is commit access to the upstream
> Subversion repository, possibly restricted to a special branch.
> Then your change identifiers would be in the same universe.
>
>
>
> 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.
If the changes are really one-way, they'd all be coming from the
upstream repository. If you make changes in 2 places, that's a
distributed system - even if your copy is never pushed back upstream.
> Imho, doesn't seem too bizzare or non-svn like.
The svn way is to get write access to a branch in the one-and-only
repository if you also want to make changes that are tracked. Or
reproduce the upstream commits in your copy letting the revision numbers
(and any external tracking references) get out of sync.
--
Les Mikesell
lesmikesell@gmail.com
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jan 11, 2011 at 11:09 PM, NN Ott <no...@gmail.com> wrote:
>
>
> On Tue, Jan 11, 2011 at 2:16 PM, Stefan Sperling <st...@elego.de> wrote:
>>
>> 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
>
> Thank you for explaining, Stefan. I'll check those links out. As you say,
> my assumptions are based more on mis-understanding than anything else.
This discussion just triggered my memory: a while ago I read in a
thread on the users list something about "foreign repository merges".
Don't know if that's something that could be useful to you, but who
knows ... See:
http://svn.haxx.se/users/archive-2010-02/0223.shtml
The thread concludes with "Don't tell anybody", so I'm not sure I'm
supposed to do just that ;-).
Cheers,
--
Johan
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by NN Ott <no...@gmail.com>.
On Tue, Jan 11, 2011 at 2:16 PM, Stefan Sperling <st...@elego.de> wrote:
> 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
>
Thank you for explaining, Stefan. I'll check those links out. As you say,
my assumptions are based more on mis-understanding than anything else.
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by Stefan Sperling <st...@elego.de>.
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
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by NN Ott <no...@gmail.com>.
On Tue, Jan 11, 2011 at 1:02 PM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Jan 11, 2011 at 12:36:58PM -0500, NN Ott wrote:
> > >
> > >
> > > >> To recap, as Les put it:
> > > >>
> > > >> I think the idea is that he'd like to see the development history of
> > > both the vendor and local changes as a continuous set of changes as you
> > > would if they were in the same repository with log and diff working
> across
> > > any points in time or branch versions. It seems like a reasonable
> thing to
> > > want, but I don't think it is possible with subversion.
> > > >
> > > >
> > >
> > > I don't think the request can be met by Subversion. Subversion is a
> > > centralized version control system; the request is met by not using a
> > > centralized version control system, but instead using a distributed
> version
> > > control system.
> > >
> > >
> > >
> >
> > With the new merge tracking capability being added, I would think this
> could
> > be on the horizon as well. A full fledged distributed system hardly is
> > needed or even what I am looking for.
>
> Merge tracking has nothing to do with this feature request.
>
> > Has such a feature request already been logged?
>
> No, and there is no point in logging it.
>
> The basic concept of a centralized version control system is that a
> repository is a single universe. Changes only "happen" in that universe
> and you cannot (easily) move or replay changes between universes without
> losing the unique identifier the change had in its original universe.
>
>
> It sounds like what you really want is commit access to the upstream
> Subversion repository, possibly restricted to a special branch.
> Then your change identifiers would be in the same universe.
>
>
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.
How is the external svn rev number + repo info not enough to enable the sort
of local tracking of copy+merge this would require?
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Tue, Jan 11, 2011 at 19:02:00 +0100:
> See here: http://subversion.apache.org/faq.html#multi-merge
This contains a broken link to <http://subversion.apache.org/links.html#misc_utils>.
Re: Feature Request: [Was: Best way to maintain patches to a 3rd
party library?]
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jan 11, 2011 at 12:36:58PM -0500, NN Ott wrote:
> >
> >
> > >> To recap, as Les put it:
> > >>
> > >> I think the idea is that he'd like to see the development history of
> > both the vendor and local changes as a continuous set of changes as you
> > would if they were in the same repository with log and diff working across
> > any points in time or branch versions. It seems like a reasonable thing to
> > want, but I don't think it is possible with subversion.
> > >
> > >
> >
> > I don't think the request can be met by Subversion. Subversion is a
> > centralized version control system; the request is met by not using a
> > centralized version control system, but instead using a distributed version
> > control system.
> >
> >
> >
>
> With the new merge tracking capability being added, I would think this could
> be on the horizon as well. A full fledged distributed system hardly is
> needed or even what I am looking for.
Merge tracking has nothing to do with this feature request.
> Has such a feature request already been logged?
No, and there is no point in logging it.
The basic concept of a centralized version control system is that a
repository is a single universe. Changes only "happen" in that universe
and you cannot (easily) move or replay changes between universes without
losing the unique identifier the change had in its original universe.
There are some ways of merging repositories, but those require admin access
to the server and are generally not considered normal use cases.
See here: http://subversion.apache.org/faq.html#multi-merge
It sounds like what you really want is commit access to the upstream
Subversion repository, possibly restricted to a special branch.
Then your change identifiers would be in the same universe.
Stefan