You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Looking through a Glass Onion." <ze...@yahoo.com> on 2008/10/06 23:32:10 UTC
Creating and using child repositories of repositories which contain externals.
Hi SVN people!
I've checked through the archives of this alias, and I've seen a few queries regarding setting up local (a.k.a. 'child') repositories of other repositories so version control can be done w/o network connectivity, then committed 'en masse' to the main repository at convenient times. The recommendation for this was to use SVK at http://svk.bestpractical.com/ -- but they don't support externals (at least not as of today's visit to http://svk.bestpractical.com/view/SVKForSubversion -- but I am investigating the 'proposal' and 'workaround'). I don't think vendor branches work here either. In the mean time...
My company's svn repository uses svn:externals in probably a unique way. We wanted to use a view-like mechanism, so we have a 'trunk' set up that contains all our components, and also contains a 'views' folder. The various views in the views folder contain sub-folders which are externals to the components of that view. For example:
/trunk/
/trunk/componentX #some component
/trunk/componentY #some other component
/trunk/componentZ #yet another component
/trunk/componentT #one last component
/trunk/views/
/trunk/views/A/
/trunk/views/A/componentX #an external to /trunk/componentX
/trunk/views/A/componentY #an external to /trunk/componentY
/trunk/views/A/componentZ #an external to /trunk/componentZ
/trunk/views/B
/trunk/views/B/componentZ #an external to /trunk/componentZ
/trunk/views/B/componentT #an external to /trunk/componentT
In this way changes to the components code is automagically propagated into the 'views' -- however (you may know where I'm going) -- if I make a change to /trunk/views/A/componentZ it doesn't show in /trunk/component/views/B/comonentZ until I commit the change. This is somewhat anathema to a 'test-before-commit' methodology, as no matter how much I test componentZ in the A view, there's no way to test-before-commit in the B view unless I cold-copy the changes into trunk/views/B, which creates other oddities for subversion when it comes time to commit (or if not, because I limit the scope of my commit, then during the update of those folders).
A solution I'd like to roll out in my own workspace(s) is to create a child/local repository of code from our main repository. Then, by checking out and committing via this child-repository I can synchronize my changes in one place, test them in the effected views, then commit these changes from my child/local repository back to the main repository. This would work pretty seamlessly, actually, if it wasn't for these externals (e.g. assuming for a moment no externals):
-- bring over the main repository code
`svn checkout http://svn/mainRepository/trunk ./MainTrunk`
-- create the child/local repository
`svnadmin create ./childRepository`
-- import the main code into the child repository
`svn import ./MainTrunk ./childRepository/trunk`
-- run svnserve
`svnserve -d -r ./childRepository
At this point I can co, update, ci any changes via the child repository (e.g. on another machine, or to a different folder on the same machine):
`svn co svn://<svnserveMachine>/trunk ./trunk`
When it comes time to check these back into the MainTrunk, I simply:
-- export childRepository code into the directory where the
mainRepository is located (using loopback to make the point):
`svn --export --force svn://127.0.0.1/trunk ./childRepository`
This 'materializes' the changes made to the child repository into the code that was originally checked out of the main repository.
At this point, I simply ci this code:
`svn ci ./childRepository
and the code goes into the mainRepository.
That said, externals make this much more involved. During the import phase, svn is smart enough to ignore the '.svn' folders, BUT it's not smart enough to ignore the externals. This mean that in the child repository, the externals are treated like separate files, and so changes to them (e.g. via another checkout workspace) do NOT get propagated at commit time. E.g. using the layout above, a change to trunk/views/A/componentZ does NOT get propogated to trunk/views/B/componentZ because the child repository sees them as different files.
I can see two ways to make this happen with externals (and to finally get to my questions, please tell me if this seems like this/either should work):
Option 1:
1) after the checkout of mainRepository, but before importing the source files into the child repository, remove all the externals. After the import, these folders can be easily replaced with another checkout of the mainRepository.
2) after the import to the child repository, re-create the externals in the childRepository by simply replicating the `svn propset svn:externals ...` commands (e.g. create a shell script that uses `svn propget svn:externals ...` of the main repository code to set the externals of the child repository code).
In this way, a change to a checkout of the child repository will get propagated to the externals folders with an update -- BUT what will happen during the export of the childRepository into the source of the checkout of the mainRepository?
-- If these changes are propagated, as I think it (of course) will, then we have the same problem as using a single checkout and copying the changes into all 'views' -- namely multiple changes to the same file (as svn is designed to complain about).
-- If these changes are NOT propagated then there seems to be no issues, and a subsequent checkin of this code into the mainRepository should go correctly.
Option 2 (again, to the meat of a meaninful question): Is there some way to get svn to ignore these externals during the import as it does the '.svn' folders and even better, to also ignore these during the export, too!)? If so, this seems like a much better solution as it's all internal to svn, and requires no special handling time or risks to folders and code.
Option 3 -- open to ideas!
Thanks for your time reading through all this. Looking forward to some solution even if it involves shell scripts and/or changes to repository hooks!
Cheers,
Steve
"All programs can be reduced to one line of code with a bug in it"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Creating and using child repositories of repositories which contain externals.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 7, 2008, at 17:54, Looking through a Glass Onion. wrote:
> Thanks for your reply and recommendations. I'll double check on the
> "advertised" limitation of svk with regard to svn:externals, and
> also see
> about route between git and scm.
>
> You probably haven't gotten to it yet, but I sent a follow-up to this
> earlier today (which did NOT contain these suggestions, so again
> thank you
> for them) -- I'm investigating using cygwin as a wrapper-that-
> supports-
> link for the Windows build environment -- links seem like what we want
> anyway, and the Windows build tools can, of course, be called from
> there.
>
> IFF, after all is said and done (and also working), I took the time
> to add
> --ignore-externals to `svn import ...` -- which is where, to my
> untrained
> svn eye it (also) belongs, do you think it would be useful, and fit
> with
> the svn mantra, or is there a better way to cover this space, and
> whatever
> related version-control spaces yet to be covered? There doesn't
> *seem*
> like there's enough time in my schedule for this, but IFF...
It's a bit peculiar to have an "--ignore-externals" option in "svn
import" since the purpose of "svn import" is to import an unversioned
directory into a repository. So that option would only apply if
you're importing from an existing working copy into a different
repository, which is an unusual use of "svn import", though it does
know about this use and does already know to ignore the .svn
directories.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Creating and using child repositories of repositories which contain externals.
Posted by "Looking through a Glass Onion." <ze...@yahoo.com>.
Hi Ryan,
Thanks for your reply and recommendations. I'll double check on the
"advertised" limitation of svk with regard to svn:externals, and also see
about route between git and scm.
You probably haven't gotten to it yet, but I sent a follow-up to this
earlier today (which did NOT contain these suggestions, so again thank you
for them) -- I'm investigating using cygwin as a wrapper-that-supports-
link for the Windows build environment -- links seem like what we want
anyway, and the Windows build tools can, of course, be called from there.
IFF, after all is said and done (and also working), I took the time to add
--ignore-externals to `svn import ...` -- which is where, to my untrained
svn eye it (also) belongs, do you think it would be useful, and fit with
the svn mantra, or is there a better way to cover this space, and whatever
related version-control spaces yet to be covered? There doesn't *seem*
like there's enough time in my schedule for this, but IFF...
Cheers,
Steve
"There is time enough for everything in the course of the day, if you do
but one thing at once, but there is not time enough in the year, if you
will do two things at a time.'
-- Lord Chesterfield to his son in the 1740s
--- On Tue, 10/7/08, Ryan Schmidt <su...@ryandesign.com> wrote:
> From: Ryan Schmidt <su...@ryandesign.com>
> Subject: Re: Creating and using child repositories of repositories which contain externals.
> To: zentechno@yahoo.com
> Cc: users@subversion.tigris.org
> Date: Tuesday, October 7, 2008, 5:39 PM
> On Oct 6, 2008, at 18:32, Looking through a Glass Onion.
> wrote:
>
> > I've checked through the archives of this alias,
> and I've seen a
> > few queries regarding setting up local (a.k.a.
> 'child')
> > repositories of other repositories so version control
> can be done w/
> > o network connectivity, then committed 'en
> masse' to the main
> > repository at convenient times. The recommendation
> for this was to
> > use SVK at http://svk.bestpractical.com/ -- but they
> don't support
> > externals (at least not as of today's visit to
> http://
> > svk.bestpractical.com/view/SVKForSubversion -- but I
> am
> > investigating the 'proposal' and
> 'workaround').
>
> svk is the tool I have most often seen recommended for this
> scenario.
> I was not aware svk had problems with externals. You'll
> have to
> address that with the developers of svk.
>
> I believe there is also a gateway between git and svn that
> can be
> used. You would use git locally, then you eventually send
> your git
> changes up to the Subversion repository. I do not know more
> about it
> than that. I believe this is the tool:
>
> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
>
>
> [snip]
>
> > Option 2 (again, to the meat of a meaninful
> question): Is
> > there some way to get svn to ignore these externals
> during the
> > import as it does the '.svn' folders and even
> better, to also
> > ignore these during the export, too!)? If so, this
> seems like a
> > much better solution as it's all internal to svn,
> and requires no
> > special handling time or risks to folders and code.
>
> You can ignore externals during export using "svn
> export --ignore-
> externals". See "svn help export".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Creating and using child repositories of repositories which contain externals.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Oct 6, 2008, at 18:32, Looking through a Glass Onion. wrote:
> I've checked through the archives of this alias, and I've seen a
> few queries regarding setting up local (a.k.a. 'child')
> repositories of other repositories so version control can be done w/
> o network connectivity, then committed 'en masse' to the main
> repository at convenient times. The recommendation for this was to
> use SVK at http://svk.bestpractical.com/ -- but they don't support
> externals (at least not as of today's visit to http://
> svk.bestpractical.com/view/SVKForSubversion -- but I am
> investigating the 'proposal' and 'workaround').
svk is the tool I have most often seen recommended for this scenario.
I was not aware svk had problems with externals. You'll have to
address that with the developers of svk.
I believe there is also a gateway between git and svn that can be
used. You would use git locally, then you eventually send your git
changes up to the Subversion repository. I do not know more about it
than that. I believe this is the tool:
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
[snip]
> Option 2 (again, to the meat of a meaninful question): Is
> there some way to get svn to ignore these externals during the
> import as it does the '.svn' folders and even better, to also
> ignore these during the export, too!)? If so, this seems like a
> much better solution as it's all internal to svn, and requires no
> special handling time or risks to folders and code.
You can ignore externals during export using "svn export --ignore-
externals". See "svn help export".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org