Hendrik Schober wrote:
> 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.
If you use a script approach to get the components, why does it matter
which are external or what layout you use? You could make a project
that contained nothing but externals references to get all the parts you
need.
>> 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.
You've glossed over how you deal with the issue of which rev of which
shared component you must use with which rev of each project. With CVS,
even though you can tag things that land in subdirectories in one step,
you still have to go through the contortions of getting the right
versions loaded into your working copy in the first place unless you are
lucky enough that everything works with HEAD revisions. The tag is only
going to help hold the set together if someone wants an exact copy. It
doesn't help as you advance to new revisions and it doesn't help
coordinate changes that affect other projects.
> 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.
But that's the only time you don't need to care. When you want to make
changes you do have to care.
>> 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.
But how do you get an appropriate version to start with?
> 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'd have that with externals pegged to revision numbers if you wanted
that. The harder part is that sometimes you want the improvements that
have been made in shared components (or even need them) and sometimes
you don't. That's the hard part, and it isn't affected that much by
losing the ability to ignore it and tag everything at once.
>> 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.
How does this script decide which rev of each thing it needs? And how
did the stuff get assembled before the tag was applied?
>> 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.
Your top level project would have external references to the shared and
third party components you want to pull in. While you are developing,
you might want to make branch copies of anything you expect to change so
your externals can reference the branch HEAD and you can have a script
that goes into each and commits without bothering anything else. You
could script tag copies of everything if necessary - but if you have
your own branch you probably can just work/build/test against the branch
head. When you are ready for a release, you'd copy each of the external
modules to a tag and adjust the external references - and merge the
changes back to the trunk.
--
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 Sat Apr 7 04:17:20 2007