See below.
On Fri, Aug 8, 2008 at 8:25 AM, Benjamin Smith-Mannschott
<bsmith.occs_at_gmail.com> wrote:
> On Aug 8, 2008, at 08:22, Michele Zamparelli wrote:
>> Hi Hilco and Ryan,
>>
>> thanks very much for your reply.
>>
>> Hilco Wijbenga wrote, On 07/08/2008 20:28:
>>>>
>>>> Suppose that M1 and M2 are two modules in the tree-like SVN repository,
>>>> which could look like:
>>>>
>>>> trunk/alpha/beta/M1 assigned to person P1
>>>> trunk/alpha/beta/M2 assigned to person P2
>>>> (any depth is allowed, depending on the circumstances)
>>>
>>> Why not alpha/beta/M1/trunk and alpha/beta/M2/trunk? If necessary, you
>>> might want to consider using svn:external to link various modules
>>> together in a separate project.
>>
>> the drawback of such an approach is that in order to check out the HEAD of
>> the entire project (ooops, I mean the trunk, to use modern SVN parlance) I
>> need to do:
>>
>> mkdir alpha/beta/M1 && cd alpha/beta/M1 && svn co URL/alpha/beta/M1/trunk
>>
>> mkdir alpha/beta/M2 && cd alpha/beta/M2 && svn co URL/alpha/beta/M2/trunk
>>
>
> (1) You can indeed use svn:externals to save you form needing to do this:
>
> /MyProduct/trunk
> /MyUtilLib/trunk
> /bundles/trunk/@svn:externals =
> MyProduct http://.../MyProduct/trunk
> MyUtilLib http://.../MyProduct/trunk
>
> (though I'm doubful as to the usefulness of doing this since MyProduct and
> MyUtilLib presumably have differing release schedules and versions (see
> below).
You wouldn't (shouldn't?) svn:external (see? you can even use it as a
verb, that's how powerful it is ;-) ) in various trunks but tags (i.e.
a tag for each module). Otherwise you lose control over the release
schedule of the aggregating project.
>> etc. etc. etc. for *all* the modules in the project, wherever they reside.
>> I do not think this is feasible for several millions line of code.
>> One also needs to know their location in the tree.
The LOC is irrelevant, it's the number of modules that you should
worry about. I found that once I started using svn:external it was
suddenly much easier to understand the structure of the project (but
YMMV, of course). Remember that you can use svn:external sort of
recursively (i.e. the module that you svn:external in can svn:external
in other modules, etcetera).
Making your dependencies clear is always a good thing (I don't mean to
imply that you don't know your dependencies). And once you are able to
break up your project into lots of separate modules you may even find
that you can build much faster. Lots of good things follow once you
are able to use smaller building blocks. But I guess I'm getting a bit
off topic now... :-)
>> Whereas the "CVS approach" would simply have:
>>
>> svn co URL/trunk and there you go.
>
> That's true but ...
>
> (2) I had a major "aha" a few months ago in my understanding of
> trunk/tags/branches. It's much easier to handle and think about if you
> always tag/branch the *whole* trunk or branch. That, however, only makes
> sense if everything that's under one trunk is always released and versioned
> together.
Yeah, definitely. If the whole "smaller building blocks" thing is not
for you then don't pretend by taggings only parts. Just tag the whole
trunk, the cost is exactly the same after all.
> - tagging and branching is eased because the layout is always the same.
> - there's no need to qualify tag names the name of the artifact being
> tagged, since it's always clear from the location of the tags directory.
>
> MyProduct/trunk # I'm working around issues with
> my_product_parent/pom.xml # subclipse+m2eclipse by moving
> my_product_submodule1/pom.xml # the parent pom.xml to sibling
> my_product_submodule2/pom.xml # position.
> /tags
> /branches
> MyUtilLib/trunk ...
> /tags/1.0.0
> /1.0.1
> /branches/1.0
>
> MyProduct contains two sub-modules, which are always released as part of
> MyProduct. They don't have versions of their own.
>
> MyProduct uses MyUtilLib, but these have separate releases and version
> numbers.
>
> That said, there is one souce of *suck* here: What if you guess wrong about
> what belongs together under one trunk? That means moving stuff between
> trunks which only works within a repository and will muddy your repo
> history. It'll also make difficult to slice the repository into separate
> repos (dumpfilter) for the top level projects at some later date.
Cheers,
Hilco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-08 18:40:45 CEST