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
<bsmith.occs_at_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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-14 10:14:10 CEST