Re: Re: VSS File Sharing

> One of the good things about sharing files is the ability for projects
> to gain from debugging that goes on in other non-related projects - yes,
> new bugs can get introduced and there is a chance that they "creep"
> across all projects that use the shared file. But in our experience
> this is extremely rare. Shared files tend to grow with additional
> related methods, that growth is organic and slow, so we end up with
> modules in our projects that provide stable and well tested libraries.
> An engineer here starts a new project by firstly going to VSS and drags
> together all the files they intend to use as a framework. It does mean
> that you get some bloat, but it's worth the cost.

Create the shared code as a bundle with its own release cycle.

Each project that uses it is currently using a specific version.

Projects advance to the next version when and if necessary... EG a new
release of the shared bundle is done (and tested) - it's benefits are
noted and ProjectX wants it immediately. ProjectY doesn't benefit so
they skip that change. They might well take the next one though.

These releases are entirely internal and are specifically to reduce
risk and to prevent projects developing against moving targets
unnecessarily.

None of this prevents the shared code model, and these bundles don't
have to be self-contained libraries, merely code structures stable at
a known point. Since they're always changed at the source merging
forward is trivial.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org