Bob Hiestand <firstname.lastname@example.org> wrote:
> On 2/8/07, Hendrik Schober <SpamTrap@gmx.de> wrote:
> > > [...]
> > > Recall that externals can point at different repositories just as
> > > easily as they can the same repository. You can't have an atomic
> > > commit against more than one repository.
> > > [...]
> > Ugh. What now?
> > We'd /really/ like to switch to svn. Hwoever, we would
> > need some way to use it so that it fits our needs, not
> > the other way around.
> > Lemme recap:
> > We have several projects considerable parts of which
> > are shared between them. Developers are hacking away
> > on those projects including the shared code, and have
> > to check in changes in the shared parts as well as in
> > the project-specific parts of the code. When projects
> > get tagged, the shared parts should get the same tag.
I'm sorry following up has taken me so long. There's
been a bit of Real Life (TM) here interfering with
> 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
> 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
I was hoping someone could suggest a slightly
different process we could use for our
development, but it seems that SVN in its
current state isn't going to work for us.
Which is sad, as it's got a few features
(like renaming) we'd really like to have.
If anyone still has any ideas how we could
proceed, I'd really like to hear from you.
again for a detailed explanation.)
(Oh, and here's another question: Do you think
it's worth to explain the problem on the
developer's list, too?)
SpamTrap@gmx.de is never read
I'm HSchober at gmx dot org
"My hope is that if more people start reading books,
the world will become a better place."
froarulv in afp
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Apr 5 13:38:14 2007