On Wed, May 14, 2008 at 5:55 AM, Ilyes Gouta <ilyes.gouta_at_gmail.com> wrote:
> Hi,
>
>> Why would you need to create a new branch for every sync?
>
> This is how it's explained in the vendor branches paragraph, in the
> SVN book. As far as I know, we can't update a branch with the
> revisions coming from another SVN repository. We can import it as a
> new code, in a new branch, (and then merge it back in the said
> long-living branch?). Am I right?
You could also use svn_load_dirs.pl to "import" the latest version,
with all the adds/deletes/updates since the previous version.
> Thank you Stephan for your valuable comments!
>
> BR,
> Ilyes Gouta.
>
>> The idea is to have a single long-living branch receiving all
>> changes from upstream serially, in the same way as upstream applied
>> them. And from that you merge into your branches to get upstream
>> changes into your code.
>
>>> Both Mercurial and git are tempting, these are distributed VCSs and at
>>> some degrees offer SVN mirroring/tracking support. But I'm still a bit
>>> worried by the merge details. SVK seems to be exactly what we need,
>>> but as a package it doesn't have the visibility other VCSs have...
>>
>> As Tom Widmer pointed out, the distributed VCSs have the advantage of making
>> it easier to sync with upstream. I'm very much interested in evaluating
>> the quality of syncs done between Subversion repositories via git, as
>> Tom suggested. I wonder if it's really lossless, and how certain types
>> of conflicts are handled.
>>
>>> Any further comments guys? Thank you again for your help.
>>
>> Tom convinced me that Subversion certainly needs a way to make this
>> easier, at least for the inter-Subversion-repository use case.
>>
>> I faintly remember talk about an augmented diff format, which would
>> mirror svn operations like copy and move that aren't expressible
>> in unidiff. No idea what came out of that effort, but it certainly
>> sounds like it would help a lot to maintain vendor branches in cases
>> where the upstream source is also using Subversion. Of course, this
>> is nothing but vapourware and won't help you solve your problem right now.
>>
>> Inter-repository merges are also possible with 1.5, but are quite
>> primitive, meaning they don't do that much more than diff+patch.
>>
>> Note that the many wrapper solutions around svn that have
>> been suggested in this thread are very, very valuable in providing
>> requirements and ideas for an internal implementation in Subversion
>> for this kind of functionality. So if you use any of those, and provide
>> feedback about them to us, it would certainly help a tiny bit -- but until
>> someone steps up and starts a serious coding effort, you'll still be
>> dependent on the wrapper solution. Which may work well for you or not,
>> that's up to you to decide.
>>
>> Stefan
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-14 18:23:54 CEST