[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Creating and using child repositories of repositories which contain externals.

From: Looking through a Glass Onion. <zentechno_at_yahoo.com>
Date: Tue, 7 Oct 2008 13:21:11 -0700 (PDT)

   Hi Rush,

    Thanks for the reply, great question, and the answer would be a
resounding "Yes!" -- but -- we've inherited our build environment from a
world of Windows code, and part of the complexity of our "views" is that
we've had to write Makefiles that uses $OS[TYPE] to spawn the correct
build tools for either environment. We're using Fedora, and I'm using OS
X to do my research, which all-in-all is a joy. That said, we're
considering cygwin, so maybe that winds up being easier than figuring this
out in svn -- I'll definitely consider this path (it may end up being a
no-op since building the code in one 'View' would mean getting it build in
another, and I'd have to be sure that wouldn't effect any of our release
mechanisms -- we definitely haven't inherited an elegant environment --
then there's the performance 'hit' to consider running the cygwin
emulation layer, etc).

I think I've even seen an svn command where the checkout will auto-create
these links, and where it also stated that it wasn't supported on Windows
and provided a link to svn:externals documentation, so maybe the
'externals' thing was all originally Windows "inspired?" Someone with
some history here will have to comment on that.

    As for the rest of you comment, another "yes" -- if someone makes
changes to the same file in two places, even if that second place is an
external of the first, or if the first place is an external of the second,
svn rightly refuses to process them. Potentially more confusingly, if
someone makes changes in one place, `svn stat` (etc) doesn't show them the
connected file as having changed. Plus the fact that externals point to
one place is playing into my considerations for what happens if/when we
branch; externals in the branch will point to the trunk by default, so
they'll have to be changed in the branch as something to remember to do.
Linking would make both of these issues disappear!

    No -- inheriting Windows hasn't made our life easy! 8^)

       Cheers,
           Steve

    "A dude with a pencil is worse than a cat with a machine gun"
                            -- Ellas Otha Bates (Bo Diddley) 1928 - 2008

--- On Tue, 10/7/08, Rush Manbert <rush_at_manbert.com> wrote:

> From: Rush Manbert <rush_at_manbert.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, 3:14 PM
> Hi Steve,
>
> Since you seem to be on some flavor of Unix, wouldn't
> it be a lot
> easier and cleaner to just set up the views as links to the
> checked
> out directories? Then all of your views that use componentX
> would be
> linked to the checked out copy of trunk/componentX, and any
> changes
> made in any view, or in the real working copy, would be
> reflected in
> the checked out trunk/componentX. You could test all of
> your views
> before you check in, and it shouldn't be too hard to
> write a script
> that knows how to construct the views directory trees.
>
> I would expect that, given the repository structure you
> showed in your
> original post, your developers could run into trouble if
> they check
> out the trunk, then modify some file, say foo.c in
> checkoutTop/
> componentX, and then also modify it in
> checkoutTop/views/A/componentX,
> then try to do a commit from checkoutTop. But I'm
> anything but a SVN
> expert, so you can't really believe anything I say. :-)
>
> - Rush
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail:
> users-help_at_subversion.tigris.org

      

---------------------------------------------------------------------
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-07 22:21:29 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.