Problem using subrepos

eric.m.lafrance at ca.abb.com eric.m.lafrance at ca.abb.com
Thu Jun 2 11:25:55 CDT 2011


Mads,

"In the previous example you used an absolute path. But ok, now we do it 
this way ..."

That is correct, I was using absolute paths in the first batch file I 
posted. But I was twice advised to use relative paths, not absolute ones 
(which is preferable, I agree), so for the sake of retesting it, I put 
back the relative paths.

"Obviously, if you had used an absolute path in .hgsub it would have used 
that without caring about the outer repos default path."

If I use an absolute path (D:\Temp\lib) in .hgsub, it doesn't make any 
difference. I still get the same error at the end.

"(Ok, other mappings than trivial relative x=x mappings can work just 
fine if Mercurial is used in a 100% centralized model without any 
distributed cloning or pulling - but then why use Mercurial?)"

We will need to have a centralized repository where the updated source 
code is available so that we can compile it. We don't want to have each 
and every developper to compile bits and pieces here and there, as it can 
add complexity to our releases management. Even distributed projects have 
that kind of "centralized" place where code gets compiled in the end, if 
my understanding is correct. We currently have a old archaic and out-dated 
SCM, and we wish to change for something else that works better. 
Everything I read about distributed system confirmed to me that it is 
possible to "emulate" a centralized way of working, that it can do just 
about anything. And so far, the best choice I though we had was to use 
Mercurial.

I'm interested to know how you would suggest we implement the usage of 
Mercurial in my business with regards to how we can link projects with 
shared libraries. It is my first experience with a distributed SCM (I'm 
working with a decendent of CVS at the moment), and there is most probably 
some things I don't quite get. So, I'm all ears for any implementation 
suggestions/hints you have for me. We haven't yet started the deployment 
of Mercurial, so now is the best time to adapt our strategy I think.

Thanks for your help ;)

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110602/49c2ef0d/attachment.htm>


More information about the Mercurial mailing list