Tracking vendor sources

["Kenneth P. Turvey" <kt...@squeakydolphin.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've pretty much decided that I'm going to have to start using a custom
kernel under Ubuntu (Linux) for various reasons that I won't bother you
with now. Since I'm going to have to use a custom kernel I don't see any
point in not keeping up with developments in the stable version of the
kernel and the various patches that I will need.  This is where I'm a bit
confused on how to use subversion to solve this problem.

The issue is that I want to use multiple vendor branches to keep the
sources in.  That's where things start getting a bit messy.  Some of the
vendor sources are distributed as patches to specific versions of the
kernel.  I'm not sure how to organize this under subversion so I can
update the patches as development proceeds along on them, merge them
altogether with some version of the kernel (not necessarily the one they
were distributed for) and maintain any of my own custom changes in trunk. 

Is there a standard way to solve this problem.  I understand that the
patch files can be checked in just as another file, but this just doesn't
seem like the way to handle this.  Shouldn't a patch really be applied on
some branch in the repository?

Thanks for any suggestions. 

- -- 
Kenneth P. Turvey <kt...@squeakydolphin.com>

XMPP  IM: kpturvey@jabber.org
Yahoo IM: kpturvey2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEIxiRi2ZgbrTULjoRAr05AJ9kfl7AuMu7re2LBLA3lBK/yZuNsgCg0AHW
Mrfei1TdaZ8Dnph+IqJbv+8=
=WzAC
-----END PGP SIGNATURE-----



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Tracking vendor sources

[Ryan Schmidt <su...@ryandesign.com>]

There is, of course, a section on vendor branches in the book, but  
since you're already using the terminology "vendor branch" I presume  
you've already read that.

I keep vendor branches of several tools we use at work, like the  
MediaWiki. I use the svn_load_dirs.pl script to keep /vendor/ 
mediawiki up to date with respect to the current released version of  
MediaWiki. I also keep our version in /tools/mediawiki. Initially  
this was created by copying the then-current version of /vendor/ 
mediawiki to /tools/mediawiki, and after that it has been kept up to  
date by merging changes from /vendor/mediawiki into it. And I can  
also apply any patches I want to /tools/mediawiki which are either  
retained when upgrading to new official versions, or marked as  
conflicts. Sometimes I report a bug and a fix, and apply the fix  
directly to /tools/mediawiki, and when the next official version  
comes around, they've fixed it in a different way, so I get a  
conflict. In that case I can either deal with the conflict normally,  
or I can first undo my local fix before merging in the new version to  
avoid the conflict entirely.

I guess the bottom line is to keep a pristine copy of whatever you're  
going to use as your baseline in /vendor/foo and then keep a copy  
with your modifications and local patches somewhere else.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Tracking vendor sources

[Nico Kadel-Garcia <nk...@comcast.net>]

Kenneth P. Turvey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I've pretty much decided that I'm going to have to start using a
> custom kernel under Ubuntu (Linux) for various reasons that I won't
> bother you with now. Since I'm going to have to use a custom kernel I
> don't see any point in not keeping up with developments in the stable
> version of the kernel and the various patches that I will need.  This
> is where I'm a bit confused on how to use subversion to solve this
> problem.
>
> The issue is that I want to use multiple vendor branches to keep the
> sources in.  That's where things start getting a bit messy.  Some of
> the vendor sources are distributed as patches to specific versions of
> the kernel.  I'm not sure how to organize this under subversion so I
> can update the patches as development proceeds along on them, merge
> them altogether with some version of the kernel (not necessarily the
> one they were distributed for) and maintain any of my own custom
> changes in trunk.
>
> Is there a standard way to solve this problem.  I understand that the
> patch files can be checked in just as another file, but this just
> doesn't seem like the way to handle this.  Shouldn't a patch really
> be applied on some branch in the repository?

I set up a "tagname" for the code from a vendor, then "tagname-vendor" for 
the tarballs and patches from that vendor involved in creating the tag. You 
can do the same with branches. 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org