On 11/12/05, Mark Thomas <[EMAIL PROTECTED]> wrote: > Costin Manolache wrote: > > I'll fix this, sorry - I think I have made few changes to my properties. > > > > What is "svn co .../current" doing - I was using this before realizing > > that current doesn't work in eclipse, never used resources/build.xml > > It is using svn:externals to bring the various modules together under > a single directory. See the svn manual for an explanation of what > externals are and how they work.
Except they don't seem to work from the eclipse plugin ( at least not for me ). > > > In the top level build.xml - jasper project is still called "jasper" - > > are we supposed to co jasper2 as jasper ? This is all so confusing and > > painfull... > > Agreed this is painful but the build script does all this for you. > build.xml and Subclipse are not totally interchangeable. They will > work together if you do the initial checkout using build.xml as per > the directions I wrote for Henri. No luck with this - subclipse refused to import. What version of eclipse/subclipse is working for you ? > Removing the jasper2 directory would be best but I didn't have the > time to fix everything this might break. Ok, but if we are checking out jasper2 directly - can we call the directory "jasper2" and use "jasper2" in the build.xml ? My problem is that there are too many variations and indirection and conflicting naming schemes that are involved - in jasper case, the project is called "Jasper", the svn dir is jasper2, and build.xml is using "jasper". And it is checked out in a different way than all other components - not from tc5.5.x ( or truck - another variation in connector ), but a subdir. > > Is it too late to just move everything in one directory - and avoid > > all this forest ? > > The current directory does exactly this using externals. Except it doesn't allways work - and it doesn't match what resources/build.xml is doing. If someone is using current/ ( as I did in CLI ) - he'll have a different structure than someone using build.xml. And if someone uses "checkout project" from eclipse - he'll get yet another structure, not compatible with either build.xml or resources/build.xml. > > > I think we allways tag and branch all the components > > ( jasper, container, connectors, etc ), it is so much easier to work > > with a single tree. Really - there are historic reasons why we had > > this in CVS, but they are long gone.. > > I did look at other structures when we moved to SVN. Our current > structure is the one that: > - enabled us to migrate in stages > - required minimal changes to our build scripts > - made little/no difference to the effort required to create a release > - required minimal manual (actually scripted) intervention to do the > migration > - enabled us to maintain the traceability of our previous releases > > All the other options I considered caused big problems in one or more > of these areas and offered little benefit. That being said, if you > have a proposal for an alternative structure then I would love to see it. Well, my proposal is to at least keep the naming and scheme consistent. No Jasper/jasper/jasper2 - only one. If current/ can be made to work with subclipse - use it in resources/build.xml as well. If not - remove it, and stick with what is used in resources/ Is it possible to "move" svn repositories, preserving history ? To be honest - if having a spaghetti tree is the price for preserving history, let's just create a new repo, copy the current head from all the subtrees we care - and move on. It sucks - but at least in future things will be simpler. Or just move back to CVS - it just worked. It ASF infra can't host it - maybe find someone who can, or move it to sourceforge or some place that can support CVS. Costin > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
