Re: Best-use scenario for vendor supplied libraries

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