On Feb 22, 2009, at 1:08 AM, void pointer wrote:
> Good question, I'm not really sure. To be honest I'm not the one
> wanting to avoid them, I have a co-worker who thinks they are the
> plague. I don't see how relative externals change much. What major
> benefits do they offer? Of course, the biggest one I've found so far
> is that if the repository URL changes the external links do not
> break. But other than that they are pretty much the same as in 1.4.
> One reason my co-worker dislikes them is because of branching. If he
> wants to work on "engine" plus the project, he believes he will have
> to create 2 branches now instead of just 1. It's more of a tedium/
> management thing for him.
> On Sun, Feb 22, 2009 at 2:04 AM, Ryan Schmidt <subversion-2009a_at_ryandesign.com
> > wrote:
> On Feb 21, 2009, at 23:45, void pointer wrote:
> I'm in a situation where I have an "engine" that several projects
> depend on. I want to make each project independent and checkouts
> shall be performed for each project. I have 2 ways I can go about
> this as far as I know:
> I can perform a checkout of each project individually and have an
> external link to the "engine". This is very conservative and as far
> as the functional end-result is concerned, this is exactly what I
> All projects could be "under" the "engine" and I could check out the
> engine and use sparse directories to exclude the projects I am not
> interested in.
> In order to do option #2, which is ideal because I like to avoid the
> use of externals that point internally to the same repository, [snip]
> Out of curiosity, why do you want to avoid externals that point to
> the same repository? It works fine. Especially with Subversion 1.5's
> new relative externals.
I would first answer questions about how your projects and the
"engine" all relate to each other.
is it possible that in the future the projects may have to be linked
with different versions of the Engine? Do the projects have separate
release cycles? Is it likely the engine may be used in other unrelated
projects at some point, possibly in different repositories?
I think the structure in option #2 is limiting if any answers to those
questions are true. The other problem I see with it is that the
developers will see the engine as the primary project based on the
hierarchy. Perhaps it is, but it sounds like it's more of a
subordinate module to each of the projects. The repository should
reflect that to avoid confusion.
Expanding on Ryan's question, why does your co-worker think externals
are so bad? I could list several problems with externals, but the
problems depend on the context of how they are used; you can avoid
most of the problems be restricting how developers use them.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-22 17:01:01 CET