Nick Seigal wrote:
>>>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) ).
Same to you. Hehe... A final comment to your remarks (which I find very
reasonable) in this post is that I'm the only person working on these
projects... so I'm sure no other people is messing things around. That
reduces the complexity for me. As we say in robotics, 'one is company,
two are multitude' (or something. I'm not native english speaker ;).
It's exactly as you describe, when there is more than one people,
there's no guarantee of equality between the versions checked out via
externals if they point to HEAD. Obviously a bad idea when you have no
total control over things (as in my case).
Kind regards,
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 20 11:26:47 2005