Many Projects/Repositories and common Libraries

Steven Scott chowarmaan at gmail.com
Wed Jan 12 09:39:22 CST 2011


On Tue, Jan 11, 2011 at 3:01 AM, Lester Caine <lester at lsces.co.uk> wrote:
> 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
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>

Thanks for the information.  I am like you, I do not have a build
system yet, but will be looking to include more with Hudson or other
tools.  The problem we have is the creation of the database via DB
scripts as well as the PHP, JavaScript, and other code/languages and
resources (images, PDFs, etc...).


More information about the Mercurial mailing list