Many Projects/Repositories and common Libraries

Lester Caine lester at lsces.co.uk
Tue Jan 11 02:01:10 CST 2011


Chris Scott wrote:
> You should use an artifact/dependency management system instead of shoe-horning this into hg.  If you're using maven, you're halfway there but need to buy into "The Maven Way".  I like apache's ivy because it gives us finer grained control.

I think this is probably part of the problem here. There isn't a single solution 
to 'project management' simply because the definition of a project is so diverse?

But 'shoe-horning this into hg' is not the real problem. It is more a matter of 
having some agreement on how all the diverse requirements can be handled in a 
common manor.

In many cases I keep getting told 'you do that in the build process' BUT I do 
not have a build process! I'm working on code in PHP, and Python and Ruby have 
exactly the same problem. There is nothing to 'compile' and no target 'binary 
build'. Packaging a distribution is now seen as simply taking a snapshot of some 
repo, or 'just clone your own copy'. Which then fails because currently there is 
no mechanism to include the bits that Chris is expecting to manage in the 
'artifact/dependency management system' ....

IDEALLY what I need is to be able to define a 'super project' which has 
subrepo's for the various sections, and even 'PHP' could be thought of as a 
subrepo since I need to know which version I'm currently targeting ( given the 
level of unnecessary changes currently being added in THAT project ). But the 
main thing is to be able to manage links to such library projects such as 
smarty, adodb and the other AJAX code bases. Traditionally these would be copies 
held in a CVS or SVN master, but surely the whole point of DVCS is that we CAN 
now maintain real links to the third party libraries, push bug fixes back to 
those master copies, or maintain a linked branch that other users of the same 
library can browse or clone. Some of those will be 'read only' subrepo's so 
should not then be trying to push anything back, something which currently seems 
to break things?

All this is still very much 'work in progress' and with so many people branching 
off and doing their own thing to meet their own requirements we seem to be 
wasting a lot of time reinventing the wheel, rather than trying to get consensus 
on an overall framework that does not need any 'shoe-horning'.

( And once again working transparently in Eclipse like ALL of the older options 
currently do would be nice - even Maven apparently does )

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php


More information about the Mercurial mailing list