On Sun, Feb 22, 2009 at 10:00 AM, John Waycott <javajohn_at_cox.net> wrote:
> 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?
>
Here are a couple of scenarios for the projects:
1. Each project will be "tagged" when we have an internal nightly build
or alpha/beta release. This means any dependencies of those projects
(specifically the "engine") need to be tagged at the appropriate revision as
well. If engine is referenced using an external, then using -r1234 in the
external property can achieve this.
2. Each project will be branched on a per-developer basis to implement
features that take a long time to complete.
3. The "engine" must be shared as far as the repository setup is
concerned. We may have 5 projects that simultaneously depend on the
"engine", and any changes we make in one project should affect all other
projects (i.e. they should get those changes when they do an update, which
would happen if engine was an external link).
4. It is also possible that not all projects require the same revision of
engine. For example, when tagging that particular branch will be locked into
a revision other than HEAD.
All of the things we want to do seem pretty typical of any usage of SVN.
Perhaps I am misunderstanding what you are really asking. I'm not really
sure what you mean by "separate release cycles". Could you explain?
I think the structure in option #2 is limiting if any answers to those
> questions are true.
>
Mind providing details here? How is it limiting?
> 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.
>
I completely agree.
> 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.
>
He states they are "error prone", however I was not able to get any details
on that out of him. I know in the past he has liked to work exclusively out
of a branch and simply merge over his changes to trunk whenever he completed
something (like a feature or bug fix), then delete his branch and recreate
it for the next thing and rinse and repeat. My guess is he's calling it
error prone because when you create a tag, it should be as simplified as
possible (no unnecessary steps) so that you completely avoid any human
error. For example, suppose we were creating a tag for archival purposes and
the revision of "engine" for that tag is supposed to be 1234, however they
mistype it as 1243. I can only guess that's the kind of "error-proneness"
he's talking about.
The process of creating a tag without externals is obviously more
convenient, since you do not first have to edit the externals and then
create the branch (tag). Without externals it's a 1 step process, and I
think that's really important to him. For what its worth, I could create a
python script to create tags for us if he wants it to be a one step process,
but maybe there's a better way.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1209664
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-22 17:15:43 CET