On Feb 16, 2009, at 17:52, Jamie Thompson wrote:
> Mark Eichin wrote:
>> The traditional approach is to have a "vendor branch"; you'd use
>> svn-load.py to pull upstream code into a branch, copy that branch to
>> your trunk, do your work on trunk, re-pull to the branch, merge from
>> the branch to trunk over time. Externals don't really help here
>> (well, you could modify svn-load to use one as the upstream source, I
>> suppose?) since what you're doing is marking "last pull" and "this
>> pull", and using that to produce a diff that you apply to your trunk
>> (and do your conflict handling there.)
>> (By "traditional" I mean "this is why CVS was written in the first
>> place" :-)
> Ah. That's a pain. "Vendor branch" seems to be the magic words I
> need to
> keep an eye out for.
> I had a play with some test repos and confirmed my way just isn't
> supported. A real shame IMHO, as it seems logical enough. It'd be
> great if
> externals were expanded or an equivalent super-external were
> Don't suppose you know if svn load dirs imports everything so my
> copy is
> exactly the same as the vendor branch? i.e. full history, etc?
> That's the
> main thing I don't want to lose, as having single big 'ol merges
> from time
> to time doesn't really help when looking at incremental diffs.
svn_load_dirs.pl does not preserve any more history from the remote
code base than is included in the repository export that you import.
Further, since it is importing exports and is not accessing the
repository directly, you will lose any Subversion properties,
externals definitions, etc.
svn_load_dirs.pl is a Perl script and is in the Subversion source
svn-load is a new script written in Python which is available at
http://free.linux.hp.com/~dannf/svn-load/ . I don't know what its
features are compared with svn_load_dirs.pl.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-17 06:21:12 CET