Brian K. Wallace wrote:
Jeremy Boynes wrote:
| Brian K. Wallace wrote:
|
|> <curiosity>
|> Wouldn't the proper use of svn:externals take care of a lot of this?
|> have svn co geronimo basically read from the externals to pull whatever
|> modules (as well as other components) you want while letting each module
|> handle its own stable/unstable structure? [obviously have a standard for
|> that structure would be HIGHLY desirable] Might be a chore setting up
|> those externals at first, but after that it'd just be there (unless new
|> modules/etc were added)
|> </curiosity>
|
|
| All our modules are in the same SVN repo so we don't need to use
| externals, we can just copy. This would be a good option for integrating
| other projects if we needed to do that at the source level. AIUI though
| they would also need to be on SVN and not all are.
|
| --
| Jeremy
|
|
Don't need, and can't use aren't quite the same, tho'. This was the part
that led me to believe (erroneously) that this thread was about
deliverables only. In your example:

.../geronimo/stable/1.0/modules/transaction
.../geronimo/stable/1.2/modules/transaction
.../geronimo/stable/2.0/modules/transaction
.../geronimo/unstable/1.3/modules/transaction
.../geronimo/unstable/2.1/modules/transaction

I'd think that transaction (as well as all other modules) might have
stable, unstable, as well as 'releases'. stable (above) could just
externalize transaction's stable (along with all the other modules), as
could unstable and 'releases' at that higher level.

Obviously this would have to be an SVN only exercise, but if you can
allow a user/developer to check out X and hide that X is made up of 50
different 'externals', but also allow them to check out just 1 of those
50 modules without having to dig through an entire structure... ?

Not thinking you were on track to restructure quite that much, so I'll
go back to 'observing'. :-)

No, you're right to bring this up. This would be a good way to handle a module structure like Alan was proposing where the modules themselves were at the top level and we had a "J2EE assembly" module that just pulled the others together.

AIUI though you can't commit across externals which would mean any work that spanned modules would need to be committed from each one which would be a little awkward. I would hope that the number of such changes will decrease so this will become only an occasional problem. One area where we will be doing work in multiple modules are the runtime/builder pairs - perhaps we can do a hybrid where e.g. jetty-runtime and jetty-builder become a pair of sub-modules under a jetty module.

--
Jeremy

Reply via email to