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 <subversion-2008c_at_ryandesign.com> wrote:
> From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
> Subject: Re: Creating and using child repositories of repositories which contain externals.
> To: zentechno_at_yahoo.com
> Cc: users_at_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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-08 00:55:21 CEST