merging 3rd party projects

[Tim Harvey <ti...@yahoo.com>]

I've been using subversion for a while now, but only on simple projects where
i'm the only one making edits.

I'm now investigating using Subversion in the workplace and have a few
questions.  I've seen this specific question asked on the maillist archives but
I did not see an answer.  This specific pattern is not in the subversion book
either unless I'm simply failing to see it in one of the examples presented
there:

Our project includes the linux kernel source tree.  Occasionally we make small
changes to it, and we occasionally want to sync in new kernel versions.  What
is the easiest way to accomplish this?  For example, should we pull in each
kernel version in an 'import' branch, then merge it into trunk which has the
previous kernel plus our changes?  When we perform this merge between the
previous kernel version, the newly imported kernel version, and our working
directory, will files that have been removed in the new kernel version be
removed from the working directory?  If conflicts arrise in a given file, is
there a 3-way diff program of choice that is typically used?

Thanks for any information.

Tim

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

Re: merging 3rd party projects

[Manuel Vacelet <ma...@gmail.com>]

2005/6/30, Tim Harvey <ti...@yahoo.com>:
> I wasn't even aware that this script existed or came with subversion (is it
> new?).  

Since 1.x line I guess.

> So, using the methodology
> of creating a branch in imports for each release you choose to sync with, this
> tool simply assists you in the creation of that import correct?

No! You create on vendor branch, you import your non versionned stuff.
Now you can load new versions of sources with svn_load_dirs in the same branch.
 

> > It doesn't replace a _real_ vendor branch (with branches & merge mgt)
> > but it's convenient.
> >
> 
> You mean that this tool is for first-time imports into your repo only right?

No I just point this tool is not a kind of bridge between different
versionning systems (CVS -> SVN for instance).
Informations about branches dependencies, delta, ... are not imported.
When you load a new version of sources you create a new delta even if
it should be very close of the one you have in the original
versionning system.

> Yes, I see that it doesn't do any merging.

It does merge but do not resolve conflict if any.


> Is there any dissadvantage to doing this?  By importing each kernel minor
> release for example, your repository will grow rather quickly.  Are there any
> performance issues based on the size of your repository due to this method?

No because you have only one branch, repository just store deltas.

You can find more informations in the Book, Chapter 7 "Vendor branches"

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

RE: merging 3rd party projects

[Ian Brockbank <ia...@scottishdance.net>]

Hi Tim,

> I wasn't even aware that this script existed or came with 
> subversion (is it
> new?).  I read over the README and from what I gather its a 
> convenience tool
> for putting tarballs, which have no source control info in 
> them (ie, no .svn or
> .CVS files) into source control for the first time.  So, 
> using the methodology
> of creating a branch in imports for each release you choose 
> to sync with, this
> tool simply assists you in the creation of that import 
> correct?  It just saves
> you the time of untaring it and importing it?  Seeing as 
> untaring and importing
> isn't that big of a step, it seems like its most useful if 
> you were to take
> advantage of its feature if using a file to specify specific 
> options for files
> (the -p cmdline option).

svn_load_dirs is more intelligent than that.  It effectively compares the
contents of your on-disk tree with a specified tree in the repository and
will do adds, updates, moves and deletes as appropriate.  If requested it
will also then do a copy to a tag.

It shows all adds and deletes before taking any action, so you can approve
or reject each one, and it allows you to point out renames at the same time.
Once you are happy with the list of actions, it goes ahead and updates the
repository.  In other words, it tries to work out what subversion actions
would have been required if you checked out the original tree and then
altered it to match the on-disk tree, and then it commits that.

It's a really neat tool which has been around since pre-1.0.  It lives
in http://svn.collab.net/repos/svn/trunk/contrib/client-side

Cheers,

Ian Brockbank
Edinburgh, Scotland
ian@scottishdance.net
http://www.scottishdance.net/


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

Re: merging 3rd party projects

[Tim Harvey <ti...@yahoo.com>]

--- Manuel Vacelet <ma...@gmail.com> wrote:

> 2005/6/30, Tim Harvey <ti...@yahoo.com>:
> > Our project includes the linux kernel source tree.  Occasionally we make
> small
> > changes to it, and we occasionally want to sync in new kernel versions. 
> What
> > is the easiest way to accomplish this?  
> 
> I don't know if it's the easiest way to manage "vendor" branches but
> I'm using svn_load_dirs script to perform the import action.
> 
> You can do that with tarballs but, IMHO, you should import files
> regulary to downsize the diff between each versions.

I wasn't even aware that this script existed or came with subversion (is it
new?).  I read over the README and from what I gather its a convenience tool
for putting tarballs, which have no source control info in them (ie, no .svn or
.CVS files) into source control for the first time.  So, using the methodology
of creating a branch in imports for each release you choose to sync with, this
tool simply assists you in the creation of that import correct?  It just saves
you the time of untaring it and importing it?  Seeing as untaring and importing
isn't that big of a step, it seems like its most useful if you were to take
advantage of its feature if using a file to specify specific options for files
(the -p cmdline option).

The one thing that bothered me in the README was where they say you might want
to make backups of your repository before you run the script in case your not
happy with the results or if the script fails for some reason.  Wouldn't you
just do a revert or obliterate on the failed import if this was the case?

> 
> It doesn't replace a _real_ vendor branch (with branches & merge mgt)
> but it's convenient.
> 

You mean that this tool is for first-time imports into your repo only right? 
Yes, I see that it doesn't do any merging.

> > For example, should we pull in each
> > kernel version in an 'import' branch, then merge it into trunk which has
> the
> > previous kernel plus our changes?  
> 
> Yes you should.

Is there any dissadvantage to doing this?  By importing each kernel minor
release for example, your repository will grow rather quickly.  Are there any
performance issues based on the size of your repository due to this method?

> 
> > When we perform this merge between the
> > previous kernel version, the newly imported kernel version, and our working
> > directory, will files that have been removed in the new kernel version be
> > removed from the working directory? 
> 
> With svn_load_dirs, yes.
> 

technically no files are removed with svn_load_dirs because its not doing any
merging, just importing a tarball correct?

Thanks for the info!

Tim

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

Re: merging 3rd party projects

[Manuel Vacelet <ma...@gmail.com>]

2005/6/30, Tim Harvey <ti...@yahoo.com>:
> Our project includes the linux kernel source tree.  Occasionally we make small
> changes to it, and we occasionally want to sync in new kernel versions.  What
> is the easiest way to accomplish this?  

I don't know if it's the easiest way to manage "vendor" branches but
I'm using svn_load_dirs script to perform the import action.

You can do that with tarballs but, IMHO, you should import files
regulary to downsize the diff between each versions.

It doesn't replace a _real_ vendor branch (with branches & merge mgt)
but it's convenient.

> For example, should we pull in each
> kernel version in an 'import' branch, then merge it into trunk which has the
> previous kernel plus our changes?  

Yes you should.

> When we perform this merge between the
> previous kernel version, the newly imported kernel version, and our working
> directory, will files that have been removed in the new kernel version be
> removed from the working directory? 

With svn_load_dirs, yes.

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