I just through the Mercurial tutorial and I like what I see. If we ignore the distributed nature, it differs from CVS and SVN in the granularity of the commands. For instance, pull, update, merge are separate tasks instead of all rolled up into one.
<br><br>I am intrigued by the distributed nature. I would find this very handy. <br><ol><li>I run a lot of thought experiments. Major overhauls to architectures. I'd like to have those under revision control while I am working on them and before I send them out to the rest of the world. I could make a branch. But managing a branch (merging changes from the main trunk as you go) is always "uncomfortable". Mercurial seems to be more natural for this.
<br></li><li>Frequently, I want to share some changes with another developer without putting in the trunk (yet). Again, I could make a new branch. And we could agree to work there. But then if they need to share another set of changes back and forth with a third developer, they may need yet another branch. Again, Mercurial seems more natural for this.
<br></li><li>(I don't think Mercurial helps me with this issue.) I frequently find myself in the middle of a big architectural change and someone will need a bug fixed in the same area I am modifying. So I end up having multiple checkouts of the code. One which is my working version that I am completely hacking, another is a "clean" checkout that I can fix bugs
in.I would probably still do this with Mercurial.</li></ol> However, I could see my Mercurial use becoming a disaster. Pulling incompatible changesets from multiple users and ending up just blowing away my checkout and starting over.
<br><br>From a Dart perspective, I am not sure there are many issues. <br><ul><li>CTest would need to be modified to understand Mercurial commands and outputs.</li><li>CTest would need to be modified if we're to support pulling from multiple repositories But I think this could just be a list of repositories to iterate over to pull.
</li><li>We'd have to decide whether it makes sense to have different Nightlies pull from different repositories.Perhaps they could appear as separate tracks automatically.<br></li></ul><br>Is there a TortoiseSVN style front end to Mercurial?
<br><br>Jim<br><br><br><div><span class="gmail_quote">On 7/18/07, <b class="gmail_sendername">Brandon Van Every</b> <<a href="mailto:bvanevery@gmail.com">bvanevery@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 7/18/07, Blezek, Daniel J (GE, Research) <<a href="mailto:blezek@crd.ge.com">blezek@crd.ge.com</a>> wrote:<br>><br>> 1) GE tends to use ClearCase for all our revision control (opposite<br>> extreme from hg). One of the main problems is merging code into the
<br>> baseline. API's change, code gets fixed twice, etc. Does hg suffer<br>> from the same problem? I know you've mentioned that branches and merges<br>> are easy, but are they a good thing? In our CVS/SVN world we tend not
<br>> to branch at all, as everyone knows "branches are evil!".<br><br>That value judgment needs some unpacking. In the centralized version<br>control world, I believe that statement means:<br><br>1) it would introduce substantial administrative overhead to the
<br>version control system to deal with it.<br><br>2) it would destabilize the source pool because we don't trust various<br>people's patches, nor can we test all the permutations.<br><br>(1) simply does not exist in the distributed version control world.
<br>Branches, patches, and merges are trivial. A branch is simply another<br>fully working repository, and the patch theory defines how they<br>differ. (2) always exists in any project no matter what technology<br>you employ. The answer to that is to work with better people.
<br><br>> 2) In SVN, we tend to have a long checkout cycle, because if you check<br>> features in without completing them, it breaks everyone else's build.<br>> What is the hg checkout-commit cycle like? I would imagine that
<br>> developers commit locally then push changes off to everyone else.<br><br>You don't check things out. You're not taking a lock on someone<br>else's repository. You pull the patches you're interested in. You do
<br>your work locally and commit your changes locally. Then you push your<br>patches to someone else's repository. They could set up an approval<br>process if they wanted to, to bless your patch. In practice, on small
<br>projects you don't need to. People just keep pushing and pulling<br>things and the patch theory figures out what goes where. You don't<br>need to do file level locking, there's no such thing. A patch defines
<br>a region of code that is changed. You can have lotsa such regions in<br>the same file, and 10 different authors working on it simultaneously.<br>As long as they know not to get in each other's way with the code<br>
they're actually changing, there are no problems. It's up to your<br>team to decide what's semantically distinct, what things are<br>separable. The way your program is arranged in files has nothing to<br>do with that.
<br><br>Merge conflicts are possible. Can't remember why they happen. When<br>they do, you can resolve them same as in any other version control<br>system. Things in conflict are demarcated; you can go in and pick the
<br>lines of text you want applied. Or there are commands to attempt to<br>resolve the conflict automagically. I've never used those. I've<br>rarely had merge conflicts either. Mostly all the patches just slide
<br>past each other.<br><br>> 2a) Do developers who rarely pull changes have problems? It would seem<br>> you could merrily work in your own little world for a long time (harder<br>> to do in SVN)...<br><br>That's a political question. Does the "official" repository change a
<br>lot? Do the changes majorly impact the whole system, or are they<br>minor bugfixes? Do you *want* to get swept along by someone else's<br>changes? It's trivial to analyze the patch differences between 2<br>
repositories. You can just choose not to incorporate various patches<br>that people have thrown into a repository.<br><br>Not so trivial is whether the people making patches have good sense as<br>to how much they do at once. Myself, if something is semantically
<br>distinct, like a specific bugfix, then I make it a separate patch. I<br>try not to do 3 things at once, although sometimes that happens.<br>Often I will check in the changes as distinct entities, rather than<br>mash them altogether, even though that's a little more work on my
<br>part. Just in case I've done 2 things that are completely trivial and<br>non-problematic, and 1 that causes things to explode. That way, if I<br>have to "back out" of the bad patch, I've still done the other 2
<br>things and I don't have to redo them. In fact, a typical approach to<br>dealing with a big problem, is to dance around it for a bit, fixing<br>all the little problems, so there's less to contend with when you
<br>sweep in for the kill.<br><br>The kind of person you don't want to work with, is the one who sits in<br>his own little sandbox, makes dozens and dozens and dozens of changes<br>locally, then pushes them all as one monolithic patch with a comment
<br>like "compatibility fixes." Jerk! Patches are only as granular as an<br>author makes them.<br><br>> 3) How do new developers get changes? Do you have a master list of<br>> developers that are willing to coordinate updates? Do you need to start
<br>> building a network of friends? 8)<br><br>Anyone can pull from an "official" repository, if you want to set it<br>up that way. This is the repository that presumably you're doing all<br>the QA testing on, analogous to the HEAD in cvs.
<br><br>To push to a repository, you grant people permissions via ssh public<br>key encryption. In Chicken-land, people who have "push" access to the<br>official repository have access to everything. It's a small project
<br>and we don't have systemic trust issues. There are ways to allocate<br>trust at a finer grain if you want.<br><br>Technologically, there's nothing special about an "official"<br>repository. It's just your political decision that *that* repository
<br>will have the QA done on it, and has lists of people with various<br>amounts of permission to push to it.<br><br>Yes if you want to get anything meaningful done in open source, you'd<br>better have friends.<br><br>
> 4) How do you manage a release? Is someone in charge of the release,<br>> and coordinates all the changes that go into the release (effectively<br>> becoming a central repository)?<br><br>Again, this is a political decision. In Chicken-land we have a CMake
<br>script that creates a tarball from a repository. We have a file that<br>contains a version number in the source tree. When Felix feels like<br>bumping up the version number, he does so. When he wants to make a<br>tarball release, he does.
<br><br>> 5) One of the central ideas in Dart is that everyone tests the same<br>> code each night (to ensure cross-platform code). Since the machines are<br>> developer-donated, how would we ensure the same code is run everywhere?
<br>> Perhaps it doesn't matter?!?<br><br>I guess you'd compare the repositories. If the result of all patch<br>applications is an identical repository, then you're testing the same<br>things. If the results difffer, then you could compute and offer a
<br>patch that transits one repository to another. Or offer a log of the<br>merge conflict if that is not possible. That's getting fancy though.<br>A simple "yes they are the same, no they are not" is fine for
<br>starters. Whether you want to know about people claiming to have a<br>repository of your code, but that differs in various ways, is a<br>political question. Most devs would call that noise, but it might be<br>a practical way to detect bugfixes, or people becoming disenchanted
<br>with your project.<br><br>> hg sounds interesting, but I'm not sure I can wrap my head around it.<br>> Perhaps we need to start a sandbox project or two.<br><br>At a user level, you just pull, edit, record, and push. It's not
<br>complicated. It's painfully simple and un-cumbersome.<br><br><br>Cheers,<br>Brandon Van Every<br>_______________________________________________<br>Dart mailing list<br><a href="mailto:Dart@public.kitware.com">Dart@public.kitware.com
</a><br><a href="http://public.kitware.com/mailman/listinfo/dart">http://public.kitware.com/mailman/listinfo/dart</a><br></blockquote></div><br>