Ryan Schmidt wrote:
> On Feb 13, 2010, at 15:43, v...@bidouille.org wrote:
>
>> I'd like to keep a mirror of the trunk of a remote directory in a
>> branch of my local repository. My use case is that I have made
>> modifications of a product for which I have only read access. As the
>> product evolves, I'd like to update while keeping my modifications.
>>
>> I thought of keeping my work in the trunk and the evolutions of the
>> remote product in a branch, and merge as necessary, simulating two
>> teams working on the same repository.
>>
>> Is this possible/is there a better way to do this ?
>
> The Vendor Branches section of the book talks about this scenario. There
> are tools to help you automate this, including the Perl script
> svn_load_dirs.pl and the Ruby script Piston.
The vendor branches section of the book was written before Subversion grew
support for foreign repository merges. If I was rewriting that section now,
I would absolutely mention this feature.
1. 'svn export' the remote branch.
2. 'svn import' the branch stuff into your own repository. Actually, I'd
recommend doing a local 'svn add' and 'svn commit' so you have the chance to
make sure the properties on the files and directories match those in the
foreign repository (see below). In either case, record the version of the
remote code that you're importing.
3. Make your customizations as normal, cimmit, etc.
4. When you need to sync up your mirror, just use:
$ svn merge foreign-...@mirrored-rev \
foreign-...@head \
mirror-working-copy
(where MIRRORED-REV was the revision of the code you imported or
last merged, of course).
It has some gotcha:
* renames in the foreign repository can really interfere with the merges
that bring them into your own repository.
* you have to make sure that when you make your initial import of the
remote code that your auto-props don't set props on the files in your
repository differently than they are in the remote one (or you run the
risk of future conflicts)
* there's no merge tracking support.
But I use this feature myself to maintain vendor branches, and I've been
pretty happy with the results.
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
