On 4/5/07, Hendrik Schober <SpamTrap@gmx.de> wrote:
> > I would personally develop your shared components separately and
> > rely on your build procedure to pull the correct compiled version.
> > Treat them as libraries maintained by a third party and enforce a
> > higher level of change control on them.
>
> I don't think this is going to work. All our
> products use many of these components and they
> are fixed and enhanced during work in those
> projects they are used in. Having to maintain
> them seperately would be a PITA. (Just think
> about tagging.)
If you can modify shared code during release of any of the sharing
project, I believe you will see many other problems that have nothing
to do with the version control software.
> > If the above is unpalatable, I would maintain tags and branches
> > across your entire repository so that everything gets tagged together,
> > and not use externals at all.
>
> This would be a PITA as well. I just counted
> >50 top-level folders under "projects", >60
> under "3rdparty" and another ~30 in "shared".
> If I wanted to tag "projects/project1" using
> this scheme I'd have to manually delete >100
> folders within the tag folder, trying to avoid
> to delete anything that's used on any of the
> halve a dozen platforms some of our projects
> are ported to. Sounds like a certain receipt
> for desaster...
Tagging isn't an issue. If you chose to not maintain separate release
cycles for shared code, that works fine by using global repository
tags across a single repository containing all the source (shared
modules and individual projects). That way you can tag the repository
using project-specific tags to pull back both the state of the project
as well as that of the shared code.
There is no reason to delete anything from the tags. If it appeals,
you can even introduce some specific naming standards into your
tagging directory by having something like:
/
/trunk
/tags
/tags/projects
/tags/projects/projectA
/tags/projects/projectB
etc.
Thank you,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 5 16:53:49 2007