Hi Stephen,
On 27/05/2009, at 10:27 PM, Stephen Butler wrote:
>>
>> I have updated it, by completely overwriting it with the contents of
>> the trunk.
>
> Do you mean the contents of the vendor1 trunk? I assume so.
>
> The most efficient way to update a vendor branch is to use a savvy
> script that will make the least number of deletes and adds. For
> instance, svn-load.
>
> http://free.linux.hp.com/~dannf/svn-load/
>
Nice script... thanks HP!
>>
>> I have now noticed that I had previously made some changes to the
>> vendor branch that I require to resurrect, in the vendor branch.
>>
>> How do I manage to do this?
>>
>> Consider the repository is now at r7700.
>> when I perform;
>> svn merge -r 7612:7615 branches/vendor1/ branches/vendor1/
>
> Try adding a peg revision to the merge source arg.
>
> merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [WCPATH]
>
> In other words,
>
> svn merge -r 7612:7615 branches/vendor1_at_7612 branches/vendor1
>
> But it's better not to patch the vendor branch itself. A vendor
> branch should be used only to capture differences between pristine
> releases of the vendor code. Your patched copy of the vendor code
> should be elsewhere, such as ^/trunk/3rd-party/vendor1 (that's
> where you should apply your merge).
>
> After committing new vendor code to ^/vendor/vendor1, merge the
> changes to your patched copy.
>
> cd /trunk/3rd-party/vendor1
> svn merge ^/vendor/vendor1
That makes a whole lot of sense. But is completely not how I was dong
it.
my branches/vendor folders all contain a FULL copy of the trunk AND
any vendor related changes.
Actually, I don't have a discreet "trunk", that is the code that is
common to all vendors.
Despite (ultimately) being the same application they are heavily
optimized and localized per installation.
And as I am finding out - that "arrangement" in Subversion terms is
causing a fairly large administrative burden - WRT tracking what files
are where and at what revision.
Looks like I am going to do some repository re-organisation.
Also just as a follow-up, the svn merge using the peg revision syntax
did not result in the update I expected. It simply updated mergeinfo
properties and not the contents of the file.
I have managed to correct by using TRAC to retrieve a copy of the file
@r7615, and edit the contents of that same file @7700.
So I have the result I wanted - which is all good... but I'm sure
there is a better way....
Not that it (almost) matters now (i just have a personal dislike for
things getting the better of me - without me understanding why).
Your repo organisation makes a lot of sense and would certainly
alleviate the problem I had this time around.
Thanks again - I appreciate the reply.
Gavin.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357042
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-30 04:08:47 CEST