[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS to SVN, best practice

From: Hendrik Schober <SpamTrap_at_gmx.de>
Date: 2007-04-06 23:43:29 CEST

Les Mikesell <lesmikesell@gmail.com> 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
  dozen platforms.
  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 [...]

  We don't.

> > 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://news.gmane.org/epvkvq$4oo$1@sea.gmane.org
> > news://news.gmane.org/eq76j6$oc3$1@sea.gmane.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
  worked on.
  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
  the build.

> 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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 6 23:44:55 2007

This is an archived mail posted to the Subversion Users mailing list.