You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Noam Tamim <no...@gmail.com> on 2006/05/15 07:04:50 UTC

way to manage external code

Hi,

There's a 3rd party code/headers/libraries tree that my project uses. My
code has dependencies on it. The 3rd party tree even has the build scripts
for building MY code.

Now, what's the correct way to manage the 3rd party code? Every few weeks I
get an update - the entire tree. Since the update can include new files as
well as *removed* files - and can even include structural changes - I use
this process for "upgrading":
1. Schedule a deletion of the old version from my WC. Commit.
2. Unpack the new version to where the old version used to live (on the WC).
Add it and commit.

The problems with this approach, if not obvious:
1. I lose history of the 3rd party tree.
2. The process requires two commits, and is therefore not atomic.

The second problem is minor, but the first may be important, if at some
point in time I will like to know at which version, for example, they've
added that variable to that struct.

What's the correct way of doing it?

Thanks,
Noam.

Re: way to manage external code

Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Ryan Schmidt wrote:
> On May 15, 2006, at 09:18, Johan Appelgren wrote:
> 
>>> There's a 3rd party code/headers/libraries tree that my project
>>> uses. 
> 
> [snip]
> 
>>> What's the correct way of doing it?
>> 
>> Have you read about vendor branches in the subversion book?
>> 
>> <http://svnbook.red-bean.com/nightly/en/svn-
>> book.html#svn.advanced.vendorbr>

The above URL is badly broken: Try this one:

http://svnbook.red-bean.com/nightly/en/svn-book.html


> And also the svn_load_dirs.pl script.
> 
> http://svnbook.red-bean.com/nightly/en/svn-
> book.html#svn.advanced.vendorbr.svn_load_dirs
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

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

Re: way to manage external code

Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 15, 2006, at 09:18, Johan Appelgren wrote:

>> There's a 3rd party code/headers/libraries tree that my project uses.

[snip]

>> What's the correct way of doing it?
>
> Have you read about vendor branches in the subversion book?
>
> <http://svnbook.red-bean.com/nightly/en/svn- 
> book.html#svn.advanced.vendorbr>

And also the svn_load_dirs.pl script.

http://svnbook.red-bean.com/nightly/en/svn- 
book.html#svn.advanced.vendorbr.svn_load_dirs



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

Re: way to manage external code

Posted by Johan Appelgren <jo...@gmail.com>.
On 5/15/06, Noam Tamim <no...@gmail.com> wrote:
> Hi,
>
> There's a 3rd party code/headers/libraries tree that my project uses. My
> code has dependencies on it. The 3rd party tree even has the build scripts
> for building MY code.
>
> Now, what's the correct way to manage the 3rd party code? Every few weeks I
> get an update - the entire tree. Since the update can include new files as
> well as *removed* files - and can even include structural changes - I use
> this process for "upgrading":
> 1. Schedule a deletion of the old version from my WC. Commit.
> 2. Unpack the new version to where the old version used to live (on the WC).
> Add it and commit.
>
> The problems with this approach, if not obvious:
> 1. I lose history of the 3rd party tree.
> 2. The process requires two commits, and is therefore not atomic.
>
> The second problem is minor, but the first may be important, if at some
> point in time I will like to know at which version, for example, they've
> added that variable to that struct.
>
> What's the correct way of doing it?
>
> Thanks,
> Noam.
>

Have you read about vendor branches in the subversion book?

<http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.vendorbr>

/Johan

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


RE: way to manage external code

Posted by Antao Almada <an...@iilab.com>.
I'm using svn:externals and it works fine:
http://svnbook.red-bean.com/nightly/pt_BR/svn.advanced.externals.html


  _____  

From: Noam Tamim [mailto:noamtm@gmail.com] 
Sent: segunda-feira, 15 de Maio de 2006 8:05
To: Subversion Users List
Subject: way to manage external code


Hi,

There's a 3rd party code/headers/libraries tree that my project uses. My
code has dependencies on it. The 3rd party tree even has the build scripts
for building MY code.

Now, what's the correct way to manage the 3rd party code? Every few weeks I
get an update - the entire tree. Since the update can include new files as
well as *removed* files - and can even include structural changes - I use
this process for "upgrading": 
1. Schedule a deletion of the old version from my WC. Commit.
2. Unpack the new version to where the old version used to live (on the WC).
Add it and commit.

The problems with this approach, if not obvious:
1. I lose history of the 3rd party tree.
2. The process requires two commits, and is therefore not atomic.

The second problem is minor, but the first may be important, if at some
point in time I will like to know at which version, for example, they've
added that variable to that struct. 

What's the correct way of doing it?

Thanks,
Noam.