On Feb 22, 2009, at 9:14 AM, Robert Dailey wrote:
> 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:
> 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.
> Each project will be branched on a per-developer basis to implement
> features that take a long time to complete.
> 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).
> 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?
You've answered my concern about separate release cycles. Each project
should be able to pull the version of the engine that it needs. If the
projects are released separately, they will likely use different
revisions of the Engine.
I do have an issue with using the -r as the only reference to an
external library; It complicates the refactoring of the repositories
as the projects grow. If you ever decide to separate the engine into
its own repository, revision numbers could end up changing after a few
svnadmin dump/loads. Externals will break no matter what when you do
that, but if the external is referenced as a tag at least you've
retained some historical information and can reconstruct old versions
if necessary. If that is not important then using the -r approach is
fine.
We have a huge source and documentation base - about 2 million unique
files, over 1000 projects and still support 15-year old software - so
that gives you an idea where I'm coming from. With code bases that big
you start to pull your hair out trying to keep it organized!
>
> 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?
>
See above :-) I made the assumption that the externals and projects
were all one project.
> 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.
I don't see adding a revision to an externals tag as being any more
error prone than editing some code. That seems like an excuse to
me :-) I agree creating scripts is really the way to go. SVN is not an
SCM system, it is just version control and you have to develop your
processes around it.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1220711
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-24 14:26:41 CET