Re: CVS to SVN, best practice

Bob Hiestand <bob.hiestand@gmail.com> 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
  plans...

> Hendrik,
>
> 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 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...

  Thanks anyway.

  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?)

> Bob

  Schobi

-- 
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