Organizing Java in Subversion?

[Robert William Vesterman <bo...@vesterman.com>]

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

Re: Organizing Java in Subversion?

[Matt Doran <ma...@papercut.biz>]

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