> > 2. If an internally developed library is to be shared between multiple
> > projects, then it should be developed from its own workspace and have
> > its own repository and versioning. From the perspective of project
> > developers, it should be treated like a closed-source vendor drop. To
> > use it, link it to the main projects via externals pointing at tagged
> > release versions of the library. Project developers may also be
> > library developers where appropriate and authorized.
> >
>
> These rules mimic what I've done ...
>
> (snip)
>
> Thinking of step 2, I still wonder if it is not too cumbersome to maintain
> the external references when there are a) a lot of external dependencies,
and b)
> some/most of these are changing rapidly (and for some reason you can't
> stay with older versions).
>
> Not that I can see any other option ATM.
I feel that it is bad policy to have the trunk codeline (or a maintained
release branch) pointed at a dependency that is under active development.
This is because our trunk codeline may soon reach a state of readiness for
promotion to a released version. To copy to the released tag, we would have
to fix all the external first. We *don't* want a released product pointing
at a dependency that is still under development and may not be in a stable
form! Instead, we create experimental branches if we want to we want to
keep up with the "bleeding edge". The experimental project vendor drop
externals we use for unstable internal and third-party libraries are pointed
at the HEAD of the trunk of the library repositories. When the version
stabilizes we point to an agreed on versioned tag off that repository.
Sometimes we do experimental branches of the main projects that point to
other places in the library repository structure (e.g. earlier revisions of
trunk, an experimental branch of the library, etc.).
In the main project trunk, the only thing that insures that we all share the
same externals is the starting point for our checkout in the main project
repository. That version always points to a stable version of the library.
All this does slow things down a bit, but we have found that a
fast-and-loose style is fine for prototyping (you can external to any
version of any library you want in an experimental branch) and pretty
terrible for releasable product development (strict rules for trunk and
maintained release branches lead to stable and reliable milestone and
release tags). The lack of structure always used to come back to haunt us
before we adopted this strategy. The classic claim (e.g. by Steve McConnell
in Project Management Survival Guide) is that research shows that 50-80 of
software project time is spent in fixing bugs (and presumably recovering
from accidents). We use a strict set of policies to try to reduce this
percentage, thus having more time to do the fun stuff, like thinking up cool
new functionality and user interfaces!
P.S. Thanks for the great conversation. It is good to get some outside
confirmation that we are on the right track (either that or we are *both*
headed over the same cliff... (grin) ).
Nick Seigal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 19 19:37:18 2005