Les Mikesell <firstname.lastname@example.org> wrote:
> Hendrik Schober wrote:
> > > >
> > > > 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 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.)
> What about tagging? Don't you want your choice of what rev of shared
> component builds with each project? You have to maintain that
> somewhere. Why is the external link harder than anywhere else?
My working copy looks like this:
With CVS, if I throw a tag on "project1", I also
tag all the shared and 3rd-party stuff. That's
good, as it allows us to get all the components
specific at this tag.
If I throw a tag in SVN, shared and 3rd-party
stuff isn't affected. That's bad, as it requires
that whoever throws the tag modifies all the
externals beforehand, so that they are nailed
to a specific revision, too.
The project I'm currently working on has ~75
folders. ~25 of these folders are checked out
shared stuff, ~25 are 3rd-party stuff (mostly
exported, so it's rather irrelevant here),
the rest is specific to the project. If I check
the project out, I get a script, too, which,
when run, pulls all the 3rd-party and shared
stuff. This project is compiled in several
configurations (library, command line app,
plugin for other app etc.) on OSX, Windows,
and several Unices, all in all about halve a
Consider this: If I have fixed a bug on Windows
I throw a tag so that all configurations on all
platforms can be built. So I throw a tag on my
whole working copy. The build servers will
checkout the project, run the script, update
to my tag, and have exactly the right version.
> > > 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...
> If you use the 'check out the whole thing' approach [...]
> > 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.
> > (See
> > news://email@example.com
> > news://firstname.lastname@example.org
> > 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?)
> You'd have to include how your workflow really goes with cvs. I don't
> see how you can edit shared components without being 'aware' that they
> are shared and affect other projects.
When I work on something, I certainly know whether
this is project-specific or shared stuff. It's just
that, for example, I don't know the shared stuff
that's exclusively used on some other platform. I
never need to change it, I don't know what it is,
and right now I don't need to care when I tag.
> Given that, why is the concept of
> using externals tied to tagged revs and separate commits to the shared
> components that much harder?
I don't think there was that many stuff we "invented"
as shared stuff. Usually code from some project gets
lifted to "shared". The point is, by then it's already
established that it's usueful outside its original
context, but it might be far from done. Also, while it
might be done enough for the original context, there
might be more work to do to make it fit for other
projects. So the shared stuff often is constantly
That's where our current taggin scheme fits in nicely:
I just tag it along with the project I use it in.
This way everybody can happily hack away on the shared
thingies I'm using, while I'm sure that, for release X
of my project I get the exact state at release X of any
shared stuff I use without having to create a release
of every shared thingy I'm using.
> You must have similar operations handled by
> your build scripts now.
I'm not sure what operations you're referring to here.
The build script for "project1" currently checks out
"project1", executes the checkout script that came with
it (which checks out all shared and exports all 3rdparty
stuff), and updates to the tag specified. Then it triggers
> On the other hand there has been a long
> discussion here about how cvs tagging differs from svn and perhaps you
> have the use case to clarify what is missing.
What we would need is that we could tag a mixture of
modules from seperate places checked out into the same
folder on the local disk with the same tag. I honestly
have no idea how this could be done with SVN's tagging
scheme. -- Which is why I asked whether there's a different
way for us to do what we do now.
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 Fri Apr 6 23:44:55 2007