You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ilyes Gouta <il...@gmail.com> on 2008/05/12 12:26:04 UTC
A special use-case using subversion
Hi!
I have a special use-case that I would like to have your opinion on
and if it's doable or not using Subversion. So, here it is:
I'd like to "clone" a public SVN repository and make the new
repository accessible to my team. Each member of my team will have his
working copy checked-out from the "cloned" repository, which is
internal, and will check-in its code to it. I'd like also to
periodically synchronize that repository with the public one to
reflect the latest public changes. So, the "cloned" repository will
act as a repo. as seen by my team members and as a "working-copy"
from the public repository point of view.
Is this doable using SVN?
Best regards,
Ilyes Gouta.
P.S: please CC me since I'm not registered on the mailing-list.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Ilyes Gouta <il...@gmail.com>.
Thanks everybody for your comments!
Indeed, Stefan's suggestion seems reasonable. Andy, thanks for the
link to the SVN book!
Regards,
Ilyes Gouta.
On Mon, May 12, 2008 at 4:37 PM, Stefan Sperling <st...@elego.de> wrote:
> On Mon, May 12, 2008 at 03:18:34PM +0100, Tom Widmer wrote:
> > Ilyes Gouta wrote:
> >> Hi!
> >>
> >> I have a special use-case that I would like to have your opinion on
> >> and if it's doable or not using Subversion. So, here it is:
> >>
> >> I'd like to "clone" a public SVN repository and make the new
> >> repository accessible to my team. Each member of my team will have his
> >> working copy checked-out from the "cloned" repository, which is
> >> internal, and will check-in its code to it. I'd like also to
> >> periodically synchronize that repository with the public one to
> >> reflect the latest public changes. So, the "cloned" repository will
> >> act as a repo. as seen by my team members and as a "working-copy"
> >> from the public repository point of view.
> >>
> >> Is this doable using SVN?
> >
> > Well, it sounds like you really need to use a Distributed VCS,
>
> For this use case, what's the practical difference between having
>
> - multiple clones of a repository holding upstream code,
> with people merging from their repositories into a central
> repository
>
> or
>
> - one repository with multiple branches, a so-called vendor branch
> for the upstream code, and the trunk that people merge into from
> their branches
>
> None, I would say. So why does he really need a distributed VCS?
>
> A nice fact to note in this context is that the Mercurial
> book recommends cloning a repository to do branching.
> With Subversion, you copy your trunk into another directory
> in the same repository instead. Same thing in practice from the
> developer's point of view. It's just that these two systems
> use different numbers of repositories to do the same thing.
>
> "Distributed vs. centralised" is not an issue here at all.
> The job that's being asked for can be done with either type
> of version control system.
>
> Stefan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Tom Widmer <to...@googlemail.com>.
Blair Zajac wrote:
> Tom Widmer wrote:
>> Another way to
>> handle integrating changes would be manually to create a patch from
>> the latest changes in the upstream repo and apply that to the vendor
>> branch in the team repo (but since Subversion doesn't have a patch
>> applier built in, you'd need to use something else for that. A DVCS? ;).
>
> You should check out piston. It handles a vendor branches very easily.
>
> http://piston.rubyforge.org/
Looks perfect for the OP.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Tom Widmer wrote:
> Stefan Sperling wrote:
>> On Mon, May 12, 2008 at 03:18:34PM +0100, Tom Widmer wrote:
>>> Ilyes Gouta wrote:
>>>> Hi!
>>>>
>>>> I have a special use-case that I would like to have your opinion on
>>>> and if it's doable or not using Subversion. So, here it is:
>>>>
>>>> I'd like to "clone" a public SVN repository and make the new
>>>> repository accessible to my team. Each member of my team will have his
>>>> working copy checked-out from the "cloned" repository, which is
>>>> internal, and will check-in its code to it. I'd like also to
>>>> periodically synchronize that repository with the public one to
>>>> reflect the latest public changes. So, the "cloned" repository will
>>>> act as a repo. as seen by my team members and as a "working-copy"
>>>> from the public repository point of view.
>>>>
>>>> Is this doable using SVN?
>>> Well, it sounds like you really need to use a Distributed VCS,
>>
>> For this use case, what's the practical difference between having
>>
>> - multiple clones of a repository holding upstream code,
>> with people merging from their repositories into a central
>> repository
>>
>> or
>>
>> - one repository with multiple branches, a so-called vendor branch
>> for the upstream code, and the trunk that people merge into from
>> their branches
>
> My understanding is that the vendor branch is a branch of the whole repo
> trunk in the OP's case. I may have misunderstood of course.
>
>> None, I would say. So why does he really need a distributed VCS?
>
> Well, strictly speaking, he doesn't need to use version control at all,
> but for convenience, a DVCS is going to be much simpler. SVN vendor
> branch handling allows you periodically to drop new versions into a
> vendor branch, using a script (perl?) that attempts to create a
> reasonable diff between versions to make merging the upstream changes
> with any local changes you've made a bit simpler than having to redo all
> the local changes manually. The fact that the source of these versions
> is another Subversion repo doesn't provide you with any extra automation
> of this process vs. just using periodic tarballs generated from that
> repo, and the process is error prone in that renames, etc. in the
> original repo aren't tracked when you update the vendor branch (at least
> not without a lot of manual fixing up). Another way to handle
> integrating changes would be manually to create a patch from the latest
> changes in the upstream repo and apply that to the vendor branch in the
> team repo (but since Subversion doesn't have a patch applier built in,
> you'd need to use something else for that. A DVCS? ;).
You should check out piston. It handles a vendor branches very easily.
http://piston.rubyforge.org/
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Tom Widmer <to...@googlemail.com>.
Stefan Sperling wrote:
> On Mon, May 12, 2008 at 03:18:34PM +0100, Tom Widmer wrote:
>> Ilyes Gouta wrote:
>>> Hi!
>>>
>>> I have a special use-case that I would like to have your opinion on
>>> and if it's doable or not using Subversion. So, here it is:
>>>
>>> I'd like to "clone" a public SVN repository and make the new
>>> repository accessible to my team. Each member of my team will have his
>>> working copy checked-out from the "cloned" repository, which is
>>> internal, and will check-in its code to it. I'd like also to
>>> periodically synchronize that repository with the public one to
>>> reflect the latest public changes. So, the "cloned" repository will
>>> act as a repo. as seen by my team members and as a "working-copy"
>>> from the public repository point of view.
>>>
>>> Is this doable using SVN?
>> Well, it sounds like you really need to use a Distributed VCS,
>
> For this use case, what's the practical difference between having
>
> - multiple clones of a repository holding upstream code,
> with people merging from their repositories into a central
> repository
>
> or
>
> - one repository with multiple branches, a so-called vendor branch
> for the upstream code, and the trunk that people merge into from
> their branches
My understanding is that the vendor branch is a branch of the whole repo
trunk in the OP's case. I may have misunderstood of course.
> None, I would say. So why does he really need a distributed VCS?
Well, strictly speaking, he doesn't need to use version control at all,
but for convenience, a DVCS is going to be much simpler. SVN vendor
branch handling allows you periodically to drop new versions into a
vendor branch, using a script (perl?) that attempts to create a
reasonable diff between versions to make merging the upstream changes
with any local changes you've made a bit simpler than having to redo all
the local changes manually. The fact that the source of these versions
is another Subversion repo doesn't provide you with any extra automation
of this process vs. just using periodic tarballs generated from that
repo, and the process is error prone in that renames, etc. in the
original repo aren't tracked when you update the vendor branch (at least
not without a lot of manual fixing up). Another way to handle
integrating changes would be manually to create a patch from the latest
changes in the upstream repo and apply that to the vendor branch in the
team repo (but since Subversion doesn't have a patch applier built in,
you'd need to use something else for that. A DVCS? ;).
Contrast:
//switch to 'main branch' if necessary. Then:
<dvcs>-svn pull|fetch|whatever
//and possibly:
<dvcs> merge|update
//each developer gets latest from team repo to their local repo:
<dvcs> pull|fetch|whatever
with the Subversion alternative, which requires running the vendor
branch script, manually fixing up any renames, etc. committing the
changes, then merging the changes into trunk in the team repo and
dealing with the conflicts, then each developer merging the changes into
their branches (if necessary).
You could write a script to help with this, of course.
> A nice fact to note in this context is that the Mercurial
> book recommends cloning a repository to do branching.
In both Git and Mercurial you can have in-repo branches as well as
whole-repo clones (in Git you often do just have a single repo with lots
of branches, though I agree this isn't the norm in Mercurial).
> With Subversion, you copy your trunk into another directory
> in the same repository instead. Same thing in practice from the
> developer's point of view.
Fine for branches in the local repo, but that doesn't help with
integrating changes in the vendor "branch" (a.k.a. the upstream repo).
It's just that these two systems
> use different numbers of repositories to do the same thing.
>
> "Distributed vs. centralised" is not an issue here at all.
> The job that's being asked for can be done with either type
> of version control system.
Not really, no. In this case, distributed is a much better fit IMHO. If
he only needs to integrate changes in the vendor branch very
occasionally and doesn't need to push them upstream, it might be
bearable, but it's going to be a nightmare otherwise (because Subversion
doesn't provide any help with keeping two separately developed repos in
sync).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Stefan Sperling <st...@elego.de>.
On Mon, May 12, 2008 at 03:18:34PM +0100, Tom Widmer wrote:
> Ilyes Gouta wrote:
>> Hi!
>>
>> I have a special use-case that I would like to have your opinion on
>> and if it's doable or not using Subversion. So, here it is:
>>
>> I'd like to "clone" a public SVN repository and make the new
>> repository accessible to my team. Each member of my team will have his
>> working copy checked-out from the "cloned" repository, which is
>> internal, and will check-in its code to it. I'd like also to
>> periodically synchronize that repository with the public one to
>> reflect the latest public changes. So, the "cloned" repository will
>> act as a repo. as seen by my team members and as a "working-copy"
>> from the public repository point of view.
>>
>> Is this doable using SVN?
>
> Well, it sounds like you really need to use a Distributed VCS,
For this use case, what's the practical difference between having
- multiple clones of a repository holding upstream code,
with people merging from their repositories into a central
repository
or
- one repository with multiple branches, a so-called vendor branch
for the upstream code, and the trunk that people merge into from
their branches
None, I would say. So why does he really need a distributed VCS?
A nice fact to note in this context is that the Mercurial
book recommends cloning a repository to do branching.
With Subversion, you copy your trunk into another directory
in the same repository instead. Same thing in practice from the
developer's point of view. It's just that these two systems
use different numbers of repositories to do the same thing.
"Distributed vs. centralised" is not an issue here at all.
The job that's being asked for can be done with either type
of version control system.
Stefan
Re: A special use-case using subversion
Posted by Tom Widmer <to...@googlemail.com>.
Ilyes Gouta wrote:
> Hi!
>
> I have a special use-case that I would like to have your opinion on
> and if it's doable or not using Subversion. So, here it is:
>
> I'd like to "clone" a public SVN repository and make the new
> repository accessible to my team. Each member of my team will have his
> working copy checked-out from the "cloned" repository, which is
> internal, and will check-in its code to it. I'd like also to
> periodically synchronize that repository with the public one to
> reflect the latest public changes. So, the "cloned" repository will
> act as a repo. as seen by my team members and as a "working-copy"
> from the public repository point of view.
>
> Is this doable using SVN?
Well, it sounds like you really need to use a Distributed VCS, and if
the upstream repo is SVN, use a plugin to your DVCS to mirror the SVN
repo. git-svn, bzr-svn and hg-svn should all do this quite well (git is
best here with full pull and push support, hg (mercurial) is fine for
pulling changes, and will improve soon with a GSoC student working on
enhancing the push-changes-upstream-from-hg-repo-to-svn-repo support).
However, all 3 have only so-so support on Windows, which may be a
problem for you (I'd say, in order, they go HG, BZR, GIT, from best to
worst Windows support).
Another option is SVK, a distributed VCS built on top of Subversion
(this will be the most seamless alternative I think - I think your repo
controlling dev or devs can manage the cloned repo using SVK commands,
but other devs just use it as a plain SVN repo, e.g. using TortoiseSVN
or similar).
See also:
http://svk.bestpractical.com/view/UsingSVKAsARepositoryMirroringSystem
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Andy Levy <an...@gmail.com>.
On Mon, May 12, 2008 at 8:26 AM, Ilyes Gouta <il...@gmail.com> wrote:
> Hi!
>
> I have a special use-case that I would like to have your opinion on
> and if it's doable or not using Subversion. So, here it is:
>
> I'd like to "clone" a public SVN repository and make the new
> repository accessible to my team. Each member of my team will have his
> working copy checked-out from the "cloned" repository, which is
> internal, and will check-in its code to it. I'd like also to
> periodically synchronize that repository with the public one to
> reflect the latest public changes. So, the "cloned" repository will
> act as a repo. as seen by my team members and as a "working-copy"
> from the public repository point of view.
>
> Is this doable using SVN?
Look into Vendor Branches.
http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Les Mikesell <le...@gmail.com>.
John Peacock wrote:
> Ilyes Gouta wrote:
>> 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...
>
> FWIW, SVK handles vendor branches without breaking a sweat. In fact, I
> have mirrors of multiple different projects that I have occasion to work
> on (including Subversion itself) and updating my local branch is usually
> as simple as:
>
> $ svk pull
>
> (from within a working copy of my local branch). This retrieves all of
> the updates from the mirror, commits it to the local mirror, then merges
> those changes to the local branch. If there is a conflict during the
> merge (which is always possible), I've got SVK set to popup a graphical
> merge editor (kdiff3 or meld), so it hardly takes any time at all.
>
> The one caveat I will mention is that if someone renames a file and
> changes it in a single commit in Subversion, then SVK can get confused
> when trying to merge to the local branch. To resolve this, I merely
> have to perform the rename in my local branch and commit it. After
> that, the merge from upstream can proceed automatically.
>
> Plus, the SVK repository is an ordinary Subversion repository, so
> technically you can host that internally using normal Subversion
> server/clients (be sure to never commit directly to the mirrored paths
> though).
Speaking of 'less visible' packages... Has anyone looked at pushmi? I
happened to notice the session mentioned in the upcoming OSCON
(http://en.oreilly.com/oscon2008/public/schedule/detail/2505) but
otherwise I don't see much publicity. Is it like SVK with more
attention to being able to use the replicated repository directly?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by John Peacock <jo...@havurah-software.org>.
Ilyes Gouta wrote:
> 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...
FWIW, SVK handles vendor branches without breaking a sweat. In fact, I
have mirrors of multiple different projects that I have occasion to work
on (including Subversion itself) and updating my local branch is usually
as simple as:
$ svk pull
(from within a working copy of my local branch). This retrieves all of
the updates from the mirror, commits it to the local mirror, then merges
those changes to the local branch. If there is a conflict during the
merge (which is always possible), I've got SVK set to popup a graphical
merge editor (kdiff3 or meld), so it hardly takes any time at all.
The one caveat I will mention is that if someone renames a file and
changes it in a single commit in Subversion, then SVK can get confused
when trying to merge to the local branch. To resolve this, I merely
have to perform the rename in my local branch and commit it. After
that, the merge from upstream can proceed automatically.
Plus, the SVK repository is an ordinary Subversion repository, so
technically you can host that internally using normal Subversion
server/clients (be sure to never commit directly to the mirrored paths
though).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 14, 2008 at 12:23:28PM -0400, Andy Levy wrote:
> On Wed, May 14, 2008 at 5:55 AM, Ilyes Gouta <il...@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.
Exactly, with this you only create the vendor branch once.
Ilyes, the basic idea is this:
When updating to a new version of the vendor's code, you check
out the vendor branch, which contains a previous version of the
vendor's code, into a working copy. Then you make that working
copy match the new version of the vendor's code -- this is the part
that should be automated better than it currently is.
Then you commit from the updated working copy to the vendor branch.
Now the vendor branch carries the new upstream version, and you can
merge from it into your own branches (and trunk).
So no, you really don't recreate the vendor branch every time you
do a sync to the vendor's most recent code. You just checkout the
vendor branch, make that working copy match the new version,
and then you commit.
To automate the updating process, we currently only have svn_load_dirs.pl,
piston (http://piston.rubyforge.org/) and similar wrapper solutions.
But they all use the same basic idea explained above.
Stefan
Re: A special use-case using subversion
Posted by Andy Levy <an...@gmail.com>.
On Wed, May 14, 2008 at 5:55 AM, Ilyes Gouta <il...@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@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Ilyes Gouta <il...@gmail.com>.
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Stefan Sperling <st...@elego.de>.
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
Re: A special use-case using subversion
Posted by Ilyes Gouta <il...@gmail.com>.
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.
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...
Any further comments guys? Thank you again for your help.
Regards,
Ilyes Gouta.
On Tue, May 13, 2008 at 7:58 PM, Benjamin Smith-Mannschott
<bs...@gmail.com> wrote:
>
> On May 12, 2008, at 14:26, Ilyes Gouta wrote:
>
>> Hi!
>>
>> I have a special use-case that I would like to have your opinion on
>> and if it's doable or not using Subversion. So, here it is:
>>
>> I'd like to "clone" a public SVN repository and make the new
>> repository accessible to my team. Each member of my team will have his
>> working copy checked-out from the "cloned" repository, which is
>> internal, and will check-in its code to it. I'd like also to
>> periodically synchronize that repository with the public one to
>> reflect the latest public changes. So, the "cloned" repository will
>> act as a repo. as seen by my team members and as a "working-copy"
>> from the public repository point of view.
>>
>> Is this doable using SVN?
>>
>
>
> You might take a look at the tools and presentations available here:
> http://www.clifford.at/
>
> Clifford Wolf has had considerable success using his svnemboss, and
> svnbranch scripts to track vendor branches and manage patch stacks (as
> branches) on top of those vendor branches.
>
> hmm... I just hopped off to clifford's web page to get you the direct link
> to his presentation, when I noticed that it was in German. Oops. I just
> heard it recently but I often forget what language I heard things in after
> the fact. I took some notes (in English) during the presentation. Perhaps
> you'll find them of some use:
>
>
> #title Notes form "Advanced Subversion" given by Clifford Wolf in Vienna on
> 2008-04-24
>
> ** svnbranch
>
> Shell script to automate branching, tagging and merging.
>
> http://svn.clifford.at/tools/trunk/svnbranch.sh
>
> Keeps track of parent (source) of branch. Both URL (location) and
> revision Propagate command to automatically merge changes from parent
> to children.
>
> Displays branch, tags, merges graphically. (as a .dot file).
>
> *** svnbranch branch
>
> Does the copy, sets the svnbranch:parent and deletes any svnbranch:tag
> property.
>
> *** svnbranch tag
>
> Same as branch, except for setting svnbranch:tag property which
> prevents other svnbranch commands (sync and propagate) from altering
> its contents.
>
> *** svnbranchs sync
>
> Merge changes from parent into working copy. updates revision on
> parent property. changes commit-ready in working copy.
>
> *** svnbranch sync URL
>
> re-parents the branch in the current working copy. merges in changes
> between old and new parent. (sounds a little like git rebase).
>
> *** svnbranch propagate
>
> started in working copy of parent. creates a shell-script
> propagate.sh. this performs recursive synchornization of all children
> of the parent. (holy-meta-programming batman!) ;-) and it's
> self-modifying to keep track of where it left off in case it's forced
> to stop for a merge conflict. huzzah!
>
> *** svnbranch merge URL
>
> Started in parent. Changes in branch (URL) relative to parent merged
> into working copy. The changes to be merged are the changes between
> branch head and last sync revision.
>
> This is used when it's time to reintegrate a branch back into its
> parent, generally making the branch obsolete.
>
> It sounds to me like svnbranch would be a great tool for managing
> feature branches. With sync we can keep up with changes in our
> parent so that we don't build up a huge merge conflict while we work
> in isolation. With svnbranch merge we then move our changes back to
> trunk when they are 'done done'.
>
> *** svnbranch diff
>
> "incoming" changes from parent.
>
> *** svnbranch show
>
> Shows a graphical view of branch history. Three variants.
>
> - list: ascii
> - graph: .dot
> - show: shows postscript of .dot using kghostview; edit script if you
> want something different.
>
> *** svnbranch:index
>
> Property on root of repository which stores an index of the branches
> in the repository.
>
> e.g
>
> tags/*
> branches/*
>
>
> This needs to be set by hand before you use svnbranch for the first
> time.
>
> * Vendor Trees
>
> To maintain local changes on external sources on which we depend and
> from which we want to track future changes.
>
> The canonical version from the vendor (unmodified):
> /vendor/foolib/1.0.
>
> Make a local branch of this to: =/trunk/foolib=. Make your local changes
> there.
>
> When the new foolib comes out: =/vendor/foolib/1.1=
>
> Then, what you'd like to do is merge the changes between 1.0 and 1.1
> to trunk. Before you can do this, however, you have to get 1.0 into
> the ancestry of 1.1. Without this SVN will see the difference as "a
> whole bunch of deletes" followed by "a whole bunch of adds". No good.
>
> ** svnemboss
>
> =svnemboss master-path wc-path=
>
> Makes the changes to wc-path that are necessary to make wc-path
> identical with master-path.
>
> svnemboss doesn't try to be smart about renames. uses rsync to do the
> actual work. It then does a status and just adds all the =?= entries
> and removes all the =!= entries.
>
> I don't know how many times I've done exactly this *by* *hand*. I don't
> know why *I* didn't think to write a script to automate it before now.
>
> See also =svn-load-dirs.pl=, which fulfills a similar purpose but works
> very differently.
>
> ** Patch stacks
>
> Maintain a series of separate patch sets as a chain of branches, on
> each of these branches maintain one patch set. By changing svnbranch
> parent property we can remove a link form this chain in order to
> remove a patch set from consideration.
>
>
> +--------------------+ +-------------------+
> | /vendor/kernel-1.0 | | vendor/kernel-1.1 |
> +--------------------+ +-------------------+
> ^ (parent)
> | +---------------+
> +--| Bug fix patch |
> +---------------+
> ^ (parent)
> | +--------------------+
> +--| some feature patch |
> +--------------------+
>
>
> With =svnbranch sync URL= you can reparent (I think *git* calls this
> "rebase") the branch "Bug fix patch" to kernel 1.1. By propagating
> the changes down your branch chain you can move your entire patch
> stack from kernel 1.0 to 1.1. Pretty slick.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: A special use-case using subversion
Posted by Benjamin Smith-Mannschott <bs...@gmail.com>.
On May 12, 2008, at 14:26, Ilyes Gouta wrote:
> Hi!
>
> I have a special use-case that I would like to have your opinion on
> and if it's doable or not using Subversion. So, here it is:
>
> I'd like to "clone" a public SVN repository and make the new
> repository accessible to my team. Each member of my team will have his
> working copy checked-out from the "cloned" repository, which is
> internal, and will check-in its code to it. I'd like also to
> periodically synchronize that repository with the public one to
> reflect the latest public changes. So, the "cloned" repository will
> act as a repo. as seen by my team members and as a "working-copy"
> from the public repository point of view.
>
> Is this doable using SVN?
>
You might take a look at the tools and presentations available here: http://www.clifford.at/
Clifford Wolf has had considerable success using his svnemboss, and
svnbranch scripts to track vendor branches and manage patch stacks (as
branches) on top of those vendor branches.
hmm... I just hopped off to clifford's web page to get you the direct
link to his presentation, when I noticed that it was in German.
Oops. I just heard it recently but I often forget what language I
heard things in after the fact. I took some notes (in English) during
the presentation. Perhaps you'll find them of some use:
#title Notes form "Advanced Subversion" given by Clifford Wolf in
Vienna on 2008-04-24
** svnbranch
Shell script to automate branching, tagging and merging.
http://svn.clifford.at/tools/trunk/svnbranch.sh
Keeps track of parent (source) of branch. Both URL (location) and
revision Propagate command to automatically merge changes from parent
to children.
Displays branch, tags, merges graphically. (as a .dot file).
*** svnbranch branch
Does the copy, sets the svnbranch:parent and deletes any svnbranch:tag
property.
*** svnbranch tag
Same as branch, except for setting svnbranch:tag property which
prevents other svnbranch commands (sync and propagate) from altering
its contents.
*** svnbranchs sync
Merge changes from parent into working copy. updates revision on
parent property. changes commit-ready in working copy.
*** svnbranch sync URL
re-parents the branch in the current working copy. merges in changes
between old and new parent. (sounds a little like git rebase).
*** svnbranch propagate
started in working copy of parent. creates a shell-script
propagate.sh. this performs recursive synchornization of all children
of the parent. (holy-meta-programming batman!) ;-) and it's
self-modifying to keep track of where it left off in case it's forced
to stop for a merge conflict. huzzah!
*** svnbranch merge URL
Started in parent. Changes in branch (URL) relative to parent merged
into working copy. The changes to be merged are the changes between
branch head and last sync revision.
This is used when it's time to reintegrate a branch back into its
parent, generally making the branch obsolete.
It sounds to me like svnbranch would be a great tool for managing
feature branches. With sync we can keep up with changes in our
parent so that we don't build up a huge merge conflict while we work
in isolation. With svnbranch merge we then move our changes back to
trunk when they are 'done done'.
*** svnbranch diff
"incoming" changes from parent.
*** svnbranch show
Shows a graphical view of branch history. Three variants.
- list: ascii
- graph: .dot
- show: shows postscript of .dot using kghostview; edit script if you
want something different.
*** svnbranch:index
Property on root of repository which stores an index of the branches
in the repository.
e.g
tags/*
branches/*
This needs to be set by hand before you use svnbranch for the first
time.
* Vendor Trees
To maintain local changes on external sources on which we depend and
from which we want to track future changes.
The canonical version from the vendor (unmodified):
/vendor/foolib/1.0.
Make a local branch of this to: =/trunk/foolib=. Make your local changes
there.
When the new foolib comes out: =/vendor/foolib/1.1=
Then, what you'd like to do is merge the changes between 1.0 and 1.1
to trunk. Before you can do this, however, you have to get 1.0 into
the ancestry of 1.1. Without this SVN will see the difference as "a
whole bunch of deletes" followed by "a whole bunch of adds". No good.
** svnemboss
=svnemboss master-path wc-path=
Makes the changes to wc-path that are necessary to make wc-path
identical with master-path.
svnemboss doesn't try to be smart about renames. uses rsync to do the
actual work. It then does a status and just adds all the =?= entries
and removes all the =!= entries.
I don't know how many times I've done exactly this *by* *hand*. I
don't
know why *I* didn't think to write a script to automate it before
now.
See also =svn-load-dirs.pl=, which fulfills a similar purpose but works
very differently.
** Patch stacks
Maintain a series of separate patch sets as a chain of branches, on
each of these branches maintain one patch set. By changing svnbranch
parent property we can remove a link form this chain in order to
remove a patch set from consideration.
+--------------------+ +-------------------+
| /vendor/kernel-1.0 | | vendor/kernel-1.1 |
+--------------------+ +-------------------+
^ (parent)
| +---------------+
+--| Bug fix patch |
+---------------+
^ (parent)
| +--------------------+
+--| some feature patch |
+--------------------+
With =svnbranch sync URL= you can reparent (I think *git* calls this
"rebase") the branch "Bug fix patch" to kernel 1.1. By propagating
the changes down your branch chain you can move your entire patch
stack from kernel 1.0 to 1.1. Pretty slick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org