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?
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
Received on 2008-05-14 18:15:41 CEST