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

Re: tagging and keeping the tree structure: an existential question

From: Benjamin Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Fri, 8 Aug 2008 17:25:44 +0200

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

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

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

---------------------------------------------------------------------
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 17:26:17 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.