[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A special use-case using subversion

From: Ilyes Gouta <ilyes.gouta_at_gmail.com>
Date: Wed, 14 May 2008 11:55:28 +0200


> 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!

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.