Multiple libraries of SCM
Eric Hopper
hopper at omnifarious.org
Fri Mar 24 18:52:58 UTC 2006
On Fri, Mar 24, 2006 at 10:10:52AM -0800, Bryan O'Sullivan wrote:
> On Fri, 2006-03-24 at 13:01 -0500, Neal Becker wrote:
>
> > I suppose the simple approach is that I need to fetch L and then fetch P if
> > I want to build the latest P.
> >
> > Is there a better way? Namely, a way that fetching P would automatically
> > update L?
>
> .....
>
> What would be more useful would be an extension that provided a feature
> similar to Subversion's externals property:
> http://svnbook.red-bean.com/en/1.0/ch07s03.html
Some have suggested that if renaming directories were implemented it
should be possible to import the library as an unrelated repository,
rename everything into a new directory, and merge with the main repo.
Then when you get library updates, you just pull them and the rename
logic automagically figures out that the changes need to be applied to
the files in their new locations.
Personally, I think this is incredibly hairy and fraught with numerous
opportunities for doing the wrong thing. So, I would prefer the
svn:externals style solution myself.
I hadn't thought of implementing it as an extension though. That would
probably be much wiser than my idea of implementing it in terms of
[decode] filters.
Have fun (if at all possible),
--
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg." --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company." -- Mark Twain
-- Eric Hopper (http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20060324/1967accb/attachment-0001.asc>
More information about the Mercurial
mailing list