Chained cloning of subrepos

[Jim Hewes]

Martin Geisler-2 wrote:
> 
> The problem is that the .hgsub file in the C/app repository is in some
> sense lying. It uses a relative path which essentially says "you can
> find the lib subrepo by looking at ../lib, relative to where you found
> this repo".
> 
This is a bit of a belated reply; I don't normally monitor the development
mailing list. But this thread pointed out a mistake I made in the batch file
I posted on the general mailing list back on July 8th. I used a relative
path that pointed outside the repository although I didn't mean to. At that
time I was kind of disappointed that cloning repositories with
subrepositories wouldn't chain the way I expected it to. But now that I
found that mistake, they do work how I'd like.


Mads Kiilerich wrote:
> 
> Subrepos are by design (?) intended to allow splitting repositories up 
> in sub repositories. Contrary to what some people (like me) expected it 
> is not directly intended to be used for "shared libraries".
> 

This is something I've been wondering: what was the intended purpose of
subrepositories and whether or not it was code sharing. So, OK, if
subrepositories are not meant for code sharing, then what is? What we're
looking for is a solution to sharing code between projects and if that's not
subrepositories then that's fine. But I think code sharing is a pretty basic
tenet of software development and I'm always surprised it's treated
seemingly as an afterthought (if at all) in source code control systems.

Since code sharing is not the intended purpose of subrepositories, our
concern is that sometime down the road changes could be made to
subrepositories that are incompatible with code sharing. The recent proposal
regarding remapping looks OK. We're a bit concerned about the future though.

Jim
-- 
View this message in context: http://mercurial.808500.n3.nabble.com/Chained-cloning-of-subrepos-tp981298p1014031.html
Sent from the Development mailing list archive at Nabble.com.