Mercurial and library repos

[Dustin Sallings]

On Feb 6, 2008, at 12:57, Gregory Allen wrote:

>> This is really not what hg was made for, so you should try a
>> different way of working.
>
> :) What is the way I should be working?

	For java projects, I think maven/buildr figured this out and made it  
not be burden on revision control systems and their users.

	I like having a good idea that my projects can be checked out and  
build at any given point in time.  I'm using rails right now and I've  
had to transplant changes from other projects to get to external code  
that was unavailable from its source.

> I've seen ForestExtension suggested, but the API is ... complex. A new
> set of commands depending on where you are in the tree is likely to
> cause confusion and error.

	Forest does look a bit too complicated and doesn't solve the  
``missing upstream'' problem.

	The transplant method isn't terrible if you are OK with cluttering  
your tree with what would be external.  Imagine a tree whose purpose  
is to handle the external project as an external project.  If it's a  
mercurial repo, have it just be one.

	hg convert can rename the parts to line them up the way  you want  
them in your tree.

	hg transplant can pull the converted patches into place.

	This may be more complicated during setup and updating parts, but  
anyone who can get to your repo can get to everything required as  
there are no external dependencies.

	But in general, we just dump the code in our source tree and talk  
about how we could theoretically make it a little better.

> I've also considered cloning the libraries repo to make a new project.
> Then I could use MQ to maintain patches to the libraries, that could
> get reapplied back up to the mainline libraries repo. Again, two sets
> of APIs that makes it complex for the user.

	It should be possible to make it transparent to the user.  I still  
prefer the maven/buildr way of having the build system deal with (and  
cache) external dependencies.  I like my code to just be the stuff  
that my team writes where I can have it that way.

-- 
Dustin Sallings

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080206/77c07d64/attachment.htm