<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Eric M Lafrance wrote, On 06/02/2011 06:25 PM:<br>
<blockquote
cite="mid:OFC0C38A31.87D09182-ON852578A3.004FB7EA-852578A3.005A439E@us.abb.com"
type="cite"><tt><font size="2">
"<i>(Ok, other mappings than trivial relative x=x mappings can
work
just <br>
fine if Mercurial is used in a 100% centralized model
without any <br>
distributed cloning or pulling - but then why use
Mercurial?)</i>"<br>
</font></tt>
<br>
<font face="sans-serif" size="2">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.</font>
<br>
</blockquote>
<br>
Yes, Mercurial works fine that way. Subrepositories with trivial
mappings also generally works fine - the subrepositories will follow
the outer repositories when you clone, push and pull.
(Subrepositories do however have some rough edges.)<br>
<br>
Non non-trivial mappings works fine if you have a 100% centralized
model where all the users only interact with one central server.
Local cloning of clones and pushing/pulling between clones will be
hard with non-trivial mappings.<br>
<br>
<blockquote
cite="mid:OFC0C38A31.87D09182-ON852578A3.004FB7EA-852578A3.005A439E@us.abb.com"
type="cite"><font face="sans-serif" size="2">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.</font><tt><font size="2"><br>
</font></tt></blockquote>
<br>
I suggest you use trivial mappings. That means that the "same"
shared library will have to appear in several places on your central
server (just like it is cloned to several developer PCs and each of
them might have many clones of the same library). The sharing of the
shared library must be handled somehow - there are at least two
options:<br>
<br>
I think a good solution in many cases is to let the owner or release
manager propagate changes between the different instances on the
central server. There is often a need for some kind of control and
qa of what is shared anyway.<br>
<br>
Another solution is to let the server make one shared repository
appear in many locations. That could be with symlinks, bind mounts,
URL rewriting, or perhaps with the "share" extension.<br>
<br>
In all cases: Remember that new revisions in a subrepo won't be used
until they are referenced from .hgsubstate.<br>
<br>
/Mads<br>
</body>
</html>