Best-use scenario for vendor supplied libraries

["Snay, Marc" <Ma...@turner.com>]

I am tasked in my department to create a 'standards of use' document for
our SubVersion repository.  In sending out my rough draft of the
document, one of the developer's posed the question of 'What about using
vendor supplied libraries'. 

 

The on-line subversion book describes a system of using a /vendor branch
that keeps a /current and a tagged /x.x version folder and then copying
the folder into the /trunk code.  It also describes how version updates
to the supplied libraries could be made by checking out the /current,
expanding the tar ball for the new version into this WC, and committing
the changes, tagging this, and viola...

 

I also have a developer who would rather just incorporate all necessary
vendor supplied libraries into his projects, and check them in/out with
his code.  We have multiple projects in the repository, so this could
lead to several project folders having the same libraries stored, or
even several folders with different versions of the same library.

 

What would you consider to be the 'best-practices' when dealing with
these libraries, and do those practices change with libraries that are
actually compiled binaries as opposed to text-based Open-Source code?

Re: Best-use scenario for vendor supplied libraries

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

On Nov 29, 2006, at 09:26, Snay, Marc wrote:

> I am tasked in my department to create a ‘standards of use’  
> document for our SubVersion repository.  In sending out my rough  
> draft of the document, one of the developer’s posed the question of  
> ‘What about using vendor supplied libraries’.
>
>
>
> The on-line subversion book describes a system of using a /vendor  
> branch that keeps a /current and a tagged /x.x version folder and  
> then copying the folder into the /trunk code.  It also describes  
> how version updates to the supplied libraries could be made by  
> checking out the /current, expanding the tar ball for the new  
> version into this WC, and committing the changes, tagging this, and  
> viola…
>
>
>
> I also have a developer who would rather just incorporate all  
> necessary vendor supplied libraries into his projects, and check  
> them in/out with his code.  We have multiple projects in the  
> repository, so this could lead to several project folders having  
> the same libraries stored, or even several folders with different  
> versions of the same library.
>
>
>
> What would you consider to be the ‘best-practices’ when dealing  
> with these libraries, and do those practices change with libraries  
> that are actually compiled binaries as opposed to text-based Open- 
> Source code?

The best practice, IMHO, is, as far as I remember, the one described  
in the book, involving putting, say, the smarty library at /vendor/ 
smarty, with subdirectories "current" for the current version and  
tagged directories for each version, e.g. "2.6.14," "2.6.13," etc.  
Rather than trying to manage updating this manually when a version  
comes out, use the svn_load_dirs.pl script which is in the client- 
side directory of the contrib directory of the Subversion source  
distribution.

Do not make any changes to the code that you import into the /vendor  
hierarchy. Instead, if you want to make changes to those libraries,  
copy the code anywhere outside of /vendor (into your project, for  
example) and modify it there. Then, to upgrade to the latest version,  
first load it into /vendor using svn_load_dirs.pl, then merge those  
changes to your project.

For example, if you copied /vendor/smarty/2.6.13 to your project into  
the directory libs/smarty, and now you've loaded 2.6.14 into /vendor  
and want to update your project's smarty to this version, simply:

cd wcofyourproject/lib/smarty
svn merge $REPO/vendor/smarty/{2.6.13,2.6.14} .
svn ci -m "updating to smarty 2.6.14"


-- 
To reply to the mailing list, use your mailer's Reply To All function


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