On Wed, May 14, 2008 at 09:41:46AM +0200, Ilyes Gouta wrote:
> Hi all,
>
> Thanks Benjamin for your input. Actually I've been comparing, for a
> while now and keeping in mind my requirements, between a pure SVN
> approach, SVK, git-svn and hgsvn.
>
> I don't really like the vendor branches concept since the upstream SVN
> repository (the trunk more specifically) is changing on a daily basis.
> It seems there will be a lot of effort synchronizing between the
> upstream repo. and our local mirror, i.e creating a new branch for
> every change, regenerating the meta-data, merging it with our trunk,
> etc.
Why would you need to create a new branch for every sync?
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
- application/pgp-signature attachment: stored
Received on 2008-05-14 11:00:09 CEST