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?
>> 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, you'd probably
shift your tags/branches folders up to the top level to make it less
cluttered during the svn conversion. You might still want externals for
the 3rd party components. It won't do any real damage to include extra
stuff in a tag. Unlike CVS, having a tagged copy has no effect at all
on the trunk version.
> 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. Given that, why is the concept of
using externals tied to tagged revs and separate commits to the shared
components that much harder? You must have similar operations handled by
your build scripts now. 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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 5 14:52:18 2007