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/05 00:35:04 UTC

Best way to maintain patches to a 3rd party library?

Hello,

I have a source library that I need to periodically import (and then patch)
for use by my code base.

The SVN Book seems to reccomend a "vendor branch" scheme where you keep a
patched branch of the "vendor drops". This would work, except that I loose
any history of the library development.  (The vendor also uses SVN and gives
read-only access to their repo.)

The other option seems to be using a pegged svn:external to the vendor's
repo, but then I need to keep my patches separate and apply them to that
folder every time I get a new wc or update the pegged version.

Is there a way to get the best of both worlds?  That is, keep access
to the library's
commit history (like an external), but also version/track my patches (like a
vendor drop)?

In other words, is there a way to have a "patched vendor branch" based on an
svn:external repo?

(Have I explained clearly what I'm asking about?)

Thanks

Re: Best way to maintain patches to a 3rd party library?

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 10, 2011, at 15:51, 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.
> 
> What would be the correct forum for such a request?

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.

Re: Best way to maintain patches to a 3rd party library?

Posted by NN Ott <no...@gmail.com>.
>
> > That's exactly right.
> >
> > Should I post this to the dev list?
>
> No. Your question is clearly a usage question so it is not appropriate
> for the dev list



Since it's been firmly established as Impossable in the
current architecture of subversion, I guess this has turned into more of a
feature request.

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.


What would be the correct forum for such a request?

Thanks

Re: Best way to maintain patches to a 3rd party library?

Posted by Les Mikesell <le...@gmail.com>.
On 1/7/2011 12:51 PM, Stefan Sperling wrote:
> On Thu, Jan 06, 2011 at 07:17:33PM -0500, NN Ott wrote:
>> That's exactly right.
>>
>> Should I post this to the dev list?
>
> No. Your question is clearly a usage question so it is not appropriate
> for the dev list.
>
> Have a look at piston: http://piston.rubyforge.org/
> Maybe that comes somewhat close to what you want.

I'm not sure that trying to coordinate 2 different version managers with 
something that has to represent changes as a sequentially numbered set 
of atomic operations even makes sense because all of the tracking 
references to revision numbers and time ranges will be wrong when 
looking at the copy.  Being able to clone and update from a read-only 
upstream copy while maintaining your own local branch work is probably 
one of the main reasons for the popularity of distributed vc's like git. 
  git-svn might do it, but your local work would have to be in the git 
repo it creates.

-- 
   Les Mikesell
    lesmikesell@gmail.com

Re: Best way to maintain patches to a 3rd party library?

Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 06, 2011 at 07:17:33PM -0500, NN Ott wrote:
> That's exactly right.
> 
> Should I post this to the dev list?

No. Your question is clearly a usage question so it is not appropriate
for the dev list.

Have a look at piston: http://piston.rubyforge.org/
Maybe that comes somewhat close to what you want.

Stefan

Re: Best way to maintain patches to a 3rd party library?

Posted by NN Ott <no...@gmail.com>.
>
>
>
>>  Can I make a local (patched) branch of an svn:external?  That way I could
>>> pull updates as needed, but still retain access to the full commit
>>> history.
>>>
>>
>> You'd need to manually (or some automated fashion) apply each commit
>> made to their repository to your own repository.
>> This is very tedious if they make a lot of commits.
>> And revision numbers between repositories wouldn't match up.
>>
>> I don't understand what the real problem you want to solve is.
>> Maybe you want to browse their history without internet access?
>> If you want to browse their history without internet access, I would
>> recommend keeping an svnsync copy of their repository on your hard drive.
>>
>
> 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.
>
>
>
That's exactly right.

Should I post this to the dev list?

Re: Best way to maintain patches to a 3rd party library?

Posted by Les Mikesell <le...@gmail.com>.
On 1/6/2011 5:41 PM, Stefan Sperling wrote:
>
>> Can I make a local (patched) branch of an svn:external?  That way I could
>> pull updates as needed, but still retain access to the full commit history.
>
> You'd need to manually (or some automated fashion) apply each commit
> made to their repository to your own repository.
> This is very tedious if they make a lot of commits.
> And revision numbers between repositories wouldn't match up.
>
> I don't understand what the real problem you want to solve is.
> Maybe you want to browse their history without internet access?
> If you want to browse their history without internet access, I would
> recommend keeping an svnsync copy of their repository on your hard drive.

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.

-- 
  Les Mikesell
    lesmikesell@gmail.com

Re: Best way to maintain patches to a 3rd party library?

Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 06, 2011 at 11:43:31AM -0500, NN Ott wrote:
> >
> > > >
> > > > I have a source library that I need to periodically import (and then
> > patch)
> > > > for use by my code base.
> > > >
> > > > The SVN Book seems to reccomend a "vendor branch" scheme where you keep
> > a
> > > > patched branch of the "vendor drops". This would work, except that I
> > loose
> > > > any history of the library development.  (The vendor also uses SVN and
> > gives
> > > > read-only access to their repo.)
> > >
> >
> >
> > The above steps can also semi-automated using svn_load_dirs:
> >
> > https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs
> >
> >
> >
> Stefan,
> 
> That is what the SVN books recommended, but then I can not access the
> original commit history of the 3rd-party library.

If you can access their svn repository, you can also access their
commit history, no?

> (The other option is to use svn:external and patch manually.)
> 
> This is exactly the crux of my question:
> 
> Can I make a local (patched) branch of an svn:external?  That way I could
> pull updates as needed, but still retain access to the full commit history.

You'd need to manually (or some automated fashion) apply each commit
made to their repository to your own repository.
This is very tedious if they make a lot of commits.
And revision numbers between repositories wouldn't match up.

I don't understand what the real problem you want to solve is.
Maybe you want to browse their history without internet access?
If you want to browse their history without internet access, I would
recommend keeping an svnsync copy of their repository on your hard drive.

Stefan

Re: Best way to maintain patches to a 3rd party library?

Posted by NN Ott <no...@gmail.com>.
>
> > >
> > > I have a source library that I need to periodically import (and then
> patch)
> > > for use by my code base.
> > >
> > > The SVN Book seems to reccomend a "vendor branch" scheme where you keep
> a
> > > patched branch of the "vendor drops". This would work, except that I
> loose
> > > any history of the library development.  (The vendor also uses SVN and
> gives
> > > read-only access to their repo.)
> >
>
>
> The above steps can also semi-automated using svn_load_dirs:
>
> https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs
>
>
>
Stefan,

That is what the SVN books recommended, but then I can not access the
original commit history of the 3rd-party library.

(The other option is to use svn:external and patch manually.)

This is exactly the crux of my question:

Can I make a local (patched) branch of an svn:external?  That way I could
pull updates as needed, but still retain access to the full commit history.

Thank you

Re: Best way to maintain patches to a 3rd party library?

Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jan 04, 2011 at 09:20:52PM -0500, Nico Kadel-Garcia wrote:
> On Tue, Jan 4, 2011 at 6:35 PM, NN Ott <no...@gmail.com> wrote:
> > Hello,
> >
> > I have a source library that I need to periodically import (and then patch)
> > for use by my code base.
> >
> > The SVN Book seems to reccomend a "vendor branch" scheme where you keep a
> > patched branch of the "vendor drops". This would work, except that I loose
> > any history of the library development.  (The vendor also uses SVN and gives
> > read-only access to their repo.)
> 
> You drop the vendor branch download on top of a copy of the old
> branch, using something like this:
> 
> 
>     svn copy svn://repo/tags//vendor-1.0 svn://repo/branches/vendor-2.0-merge
>     scn co svn://repo/branches/vendor/2.0-merge 2.0-merge
> 
>     tar xzvf vendor-2.0.tar.gz
>     rsync -avH --exclude=.svn --delete vendor.2.0/ 2.0-merge/
>     cd 2.0
>     svn status
>     [ Add necessary files, delete missing files, set whatever svn
> properties you need, etc. etc.

The above steps can also semi-automated using svn_load_dirs:
https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs

Stefan

> 
>     svn commit
>     svn copy. svn://repo/tags/vendor-2.0
> 
> Delete svn://repo/branches/vendor-2.0-merge if you feel so inclined.
> 
> This will combine the forced upgrade into a single commit. Don't do
> *ANY* other work in those branches and tags.
> 
> You can then try to merge that tag with your trunk or other branches,
> although SVN merges are not their strongest feature.

Re: Best way to maintain patches to a 3rd party library?

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Jan 4, 2011 at 6:35 PM, NN Ott <no...@gmail.com> wrote:
> Hello,
>
> I have a source library that I need to periodically import (and then patch)
> for use by my code base.
>
> The SVN Book seems to reccomend a "vendor branch" scheme where you keep a
> patched branch of the "vendor drops". This would work, except that I loose
> any history of the library development.  (The vendor also uses SVN and gives
> read-only access to their repo.)

You drop the vendor branch download on top of a copy of the old
branch, using something like this:


    svn copy svn://repo/tags//vendor-1.0 svn://repo/branches/vendor-2.0-merge
    scn co svn://repo/branches/vendor/2.0-merge 2.0-merge

    tar xzvf vendor-2.0.tar.gz
    rsync -avH --exclude=.svn --delete vendor.2.0/ 2.0-merge/
    cd 2.0
    svn status
    [ Add necessary files, delete missing files, set whatever svn
properties you need, etc. etc.

    svn commit
    svn copy. svn://repo/tags/vendor-2.0

Delete svn://repo/branches/vendor-2.0-merge if you feel so inclined.

This will combine the forced upgrade into a single commit. Don't do
*ANY* other work in those branches and tags.

You can then try to merge that tag with your trunk or other branches,
although SVN merges are not their strongest feature.