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

Re: Organizing Java in Subversion?

From: Matt Doran <matt.doran_at_papercut.biz>
Date: 2006-04-14 04:15:54 CEST

Hi there,

If each of those java packages really represents a different project
that can be tagged, branched separately from each other you need to have
a structure like this:

/utils-db/trunk/com/blah/utils/db/
/utils-db/branches
/utils-db/tags
/someproject/trunk/com/blah/someproject
/someproject/branches
/someproject/tags

Each separate project has a distinct root (utils-db, someproject, etc).
Each of these has a trunk, branches, tags folder. The trunk contains
the standard java package directory structure.

There's no point having all these separate roots unless the projects are
independent. It will just create unnecessary overhead. For example,
if you want to create a branch that develops a new feature that requires
changes to "utils-db" and "utils-things", then you will need to create
branches in all these projects and manage the merging of each of these
back to trunk.

So you really need to think about your project structure and create a
separate svn root for those files that you consider as a single unit.

Hope this clarifies things.

Cheers,
Matt

Robert William Vesterman wrote:
> I've been migrating various things to Subversion. I created one main
> repository, with several distinct projects. For each project, I gave
> the root directory trunk, branches, and tags subdirectories, which
> seems to be the generally suggested scheme.
>
> But I haven't yet migrated my Java code, and I'm having a hard time
> thinking of a decent way to do so.
>
> This might be a somewhat long and rambling message; I apologize in
> advance.
>
> Forgetting about Subversion for a second, the Java code is stored in a
> typical Java package-directory-tree way, i.e. starting at the top, the
> directories represent the reverse of the associated internet domain
> name, and eventually get down to actual code units of some sort. So,
> for example:
>
> /com
> /com/blah
> /com/blah/utils
> /com/blah/utils/db
> /com/blah/utils/thing
> /com/blah/someproject
> /com/blah/someproject/stuff
> /com/blah/otherproject
> /com/bling/something
> /org/bleh/whatever
>
> And so forth. Now, I should mention that I do actually have multiple
> distinct domain names involved here, and moreover some of them might
> use code from others. And within any given one, there could be many
> distinct units (for example, a library), which could have a high
> degree of interusage.
>
> By default, following the typical Subversion suggestion, I would make
> branches, tags, and trunk in each thing that is somehow considered a
> distinct project. That would lead to something like:
>
>
> /com
> /com/blah
> /com/blah/utils
> /com/blah/utils/db/branches
> /com/blah/utils/db/tags
> /com/blah/utils/db/trunk
> /com/blah/utils/thing/branches
> /com/blah/utils/thing/tags
> /com/blah/utils/thing/trunk
> /com/blah/someproject/branches
> /com/blah/someproject/tags
> /com/blah/someproject/trunk
> /com/blah/someproject/trunk/stuff
> /com/blah/otherproject/branches
> /com/blah/otherproject/tags
> /com/blah/otherproject/trunk
> /com/bling/something/branches
> /com/bling/something/tags
> /com/bling/something/trunk
> /org/bleh/whatever/branches
> /org/bleh/whatever/tags
> /org/bleh/whatever/trunk
>
> Which is fine, except...
>
> Java requires things to be in the expected tree structure; this
> "trunk" and "branches" and so forth will screw it up.
>
> Now, I understand that you would actually be checking out the various
> trunks (or whatever), not that whole repository structure, when it
> came time to use it. But...
>
> That's a whole lot of separate "checking out". It would be nice to
> have a way to easily check out everything you'll need, in one shot.
> Something which would be facilitated by the following, instead of the
> scheme above:
>
> /java/branches
> /java/tags
> /java/trunk
>
> But this kind of defeats the purpose of "branches/tags/trunk" in the
> first place - there are going to be a whole bunch of completely
> unrelated things under "java", and it doesn't make any sense at all to
> assign (for example) a specific version number across all of them.
>
> So, I was thinking maybe svn:externals could help, but I don't see
> how, as it requires externals to be made subdirectories of the main
> (non-external) directory, yet Java is going to require differently -
> all of those Java files have to be in a particular place in the tree,
> and that place probably is not a subdirectory of the "main" part of
> the tree that you're currently concerned with.
>
> So, now I'm thinking to have shell scripts for various projects, doing
> lots of separate "svn checkouts", or "svn updates", or whatever, for
> everything that's appropriate to the current project. But that seems
> - I don't know, bad - like it should be redundant if I just had things
> organized in some fundamentally decent way that I currently am just
> not envisioning.
>
> In fact, that's the way that all of my ideas so far have seemed.
>
> So, ummm, I guess my question is: uh, what? Huh? Any idea?
>
> Thanks in advance for any help.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 14 04:17:17 2006

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.