tag:blogger.com,1999:blog-3669809752172683097.post7638117255549536471..comments2024-02-08T04:04:28.385-08:00Comments on Cyclopedia Square: Cutting Edge Revision ControlBryanhttp://www.blogger.com/profile/11394436715172971234noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-3669809752172683097.post-8382275852497460592010-11-12T08:50:21.547-08:002010-11-12T08:50:21.547-08:00Thanks for a well written, pleasant to read articl...Thanks for a well written, pleasant to read article.<br /><br />Though I am quite happy with your pragmatic, ymmv benchmarking, I thought you might be interested in a comment on what hg and git are doing on that initial commit. This will not be a very authoritative one.<br /><br />hg stores its repository in a structure mirroring the working directory, and as you commit it calculates and stores differentially compressed logs on a per-file basis. The head copy is in fact basically the working directory copy, rather than it being stored anywhere else at this point.<br /><br />The initial commit, then, and added files in subsequent commits, have nothing much to do, apart from create an essentially empty structure, O(#files) rather than the size of all content. It's more or less a lndir but with hard links, if that helps.<br /><br />So, its no surprise this doesn't take very long. Not that that undermines the advantage.<br /><br />git, on the other hand, makes no assumption that the previous version of a file is a good one to differentially compress against, nor that files with different paths are essentially incomparable. Rather, you might say it stores by content or at least not according to the original working directory paths. Everything is duplicately stored in the git repository directory by a hash of the content. Then, loose associations and differential compression can be made according to some clever match-testing for what would make good deltas.<br /><br />An initial commit has as much work as a similarly sized subsequent commit. That is, it has to hash the path and content of every file in commit, and depending on your settings may also be packing according to this similarity testing. One of the properties that spins out of this is the magic rename handling that you observed. The other is that compression and performance gains are observed as much for inter-file similarities as much as for the intra-file-history similarities usually considered. Naturally, the usually considered cases are prominent in most source repositories and efficiency in working with these dominates in many.<br /><br />So, anyway, its a minute of what some might call clever, cool indexing-fu.<br /><br />You will detect that I have more experience with git and have very few complaints. I would choose git by default for a new project of just about any scale. I think hg has the edge for portability, and I keep fossil on a usb stick as a trial of that aspect.David Eisnerhttp://trinitysystems.comnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-41331987020816278392008-01-12T13:36:00.000-08:002008-01-12T13:36:00.000-08:00Hi,The "serious darcs bugs" referred to have now b...Hi,<BR/><BR/>The "serious darcs bugs" referred to have now been addressed with Darcs 2, whic in pre-release. You can read about it <A HREF="http://wiki.darcs.net/DarcsWiki/DarcsTwo" REL="nofollow">here</A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-68059096566972434412007-08-01T15:58:00.000-07:002007-08-01T15:58:00.000-07:00Clarification: git has the -M flag for rename dete...Clarification: git has the -M flag for rename detection _purely_ for compatibility reasons. The default is _not_ to use it, since for example GNU patch does not grok the format. (Many use git to work around other SCMs shortcomings, and you will never know that it was actually git under the hood.)<BR/><BR/>And the -C flag is for copy detection, which is also a nice feature.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-69630664083310236412007-04-24T03:17:00.000-07:002007-04-24T03:17:00.000-07:00In git you get the renames/copies in diff with the...In git you get the renames/copies in diff with the flags -M/-C.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-82598440621634903982007-03-15T02:01:00.000-07:002007-03-15T02:01:00.000-07:00Bazaar has tried to follow the edict of "make it w...Bazaar has tried to follow the edict of "make it work, make it right, make it fast." We're focussing on fast now, and the 0.15 release makes some operations twice as fast, with some more gains still to be picked up.Anonymoushttps://www.blogger.com/profile/12916414304823732003noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-48717007106301576962007-03-10T08:14:00.000-08:002007-03-10T08:14:00.000-08:00John,Thanks for your mercurial tips. Your revisio...John,<BR/><BR/>Thanks for your mercurial tips. <A HREF="http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Distributed.html" REL="nofollow">Your revision control blog entry</A> was one of my introductions to these tools.<BR/><BR/>My version of hg (0.9.3) doesn't seem to understand the fetch command, but it does have addremove which I hadn't noticed before. Very cool.<BR/><BR/>I'll have to try out your diff tips too.Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-10325362103132156412007-03-08T20:27:00.000-08:002007-03-08T20:27:00.000-08:00A couple of things about Mercurial...#1. The "hg f...A couple of things about Mercurial...<BR/><BR/>#1. The "hg fetch" command automates the pull/update or pull/merge/commit process. Just use "hg fetch" instead of "hg pull" and the three steps magically turn into one.<BR/><BR/>#2. hg addremove -s uses a rename detection heuristic like git to detect renames that may have occured in the filesystem. The nice thing is that this is optional in Mercurial. You do have a choice about telling the system exactly what renamed, rather than having it guess.<BR/><BR/>#3. hg export and hg export --git give you nicer diffs than hg log -vp or hg diff will. Note esepcially the --switch-parent option to hg export, which when used on a merge changeset, switches which parent the changeset is diffed against. Very slick IMHO.<BR/><BR/>With hg export --git, you get the exact same patch format as git, which Mercurial can both import and export.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-72203508567190264352007-03-07T11:30:00.000-08:002007-03-07T11:30:00.000-08:00In regards to darcs, it does have some serious iss...In regards to darcs, it does have some serious issues. It is also probably the nicest to use when it is not having said issues. Just read the archives for the darcs mailing list, you'll see tons of people asking about hangs, memory issues, slowness, etc.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-90411381585758837922007-03-07T07:43:00.000-08:002007-03-07T07:43:00.000-08:00I liked your high-level overview of the tools. I ...I liked your high-level overview of the tools. I have been using hg for a while mainly because we have Win machines that need to be part of the development. Regarding the ease of typing the names... alias is your friend! I use dvorak, and hg is on the same finger. Well, that is, it _was_ that way until alias h=hg came around :)<BR/><BR/>Interesting bits about the "auto-guess-your-rename" feature in git. Not sure whether I like it or not. PFM (Pure Freaking Magic) behind my back. I'll have to check it out. Renames are the one thing I don't like in hg.Anonymoushttps://www.blogger.com/profile/18055286161550269129noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-66861010473187886462007-03-06T16:39:00.000-08:002007-03-06T16:39:00.000-08:00Also, in Dvorak, the 'h' and 'g' are both on the r...Also, in Dvorak, the 'h' and 'g' are both on the right-hand index finger, so it doesn't score any typeability points from me =)Vineethttps://www.blogger.com/profile/12361589059366845911noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-76747298272490624562007-03-06T16:35:00.000-08:002007-03-06T16:35:00.000-08:00Subversion's branching/merging support becomes dec...Subversion's branching/merging support becomes decent if you use svnmerge.py to help track merges. It stores merge metadata and allows you to cherry-pick changesets across branches, avoiding changesets that have already been merged and/or explicitly ignored. Compared to using an SCM that does merge-tracking internally, it is sort of a hack, but it actually works pretty well if you're using subversion.Vineethttps://www.blogger.com/profile/12361589059366845911noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-14272039605949777022007-03-06T13:10:00.000-08:002007-03-06T13:10:00.000-08:00Masklinn: It is darcs 1.0.8. I hope the other co...Masklinn: It is darcs 1.0.8. I hope the other comments about the darcs bug, or corner-case as the case may be, answered your second question. I haven't personally experienced it in my small amount of testing, but it sounds nasty enough that I figured some warning was due. I hope I'm not just spreading FUD.<BR/><BR/>Anonymous #7, your css tip wins. Thank you so much.<BR/><BR/>Others, thanks for the comments. I have heard of SVK but haven't tried it out. It sounds like too weird of a hybrid for me. One of the things I love about these distributed revision control systems is that there is no need for a central server. You can enter any existing directory (your home directory, /etc, whatever) and turn it into a repository in place. Heck, you could turn it into four different repositories if you have each tool ignore the other tools' meta-data directories (that's just crazy, don't really do it). No fiddling with apache configs and webdav for network support either. Do you get any of that with svk?Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-24001898380744660312007-03-06T12:40:00.000-08:002007-03-06T12:40:00.000-08:00Kurt,if you pull from the packaging repo into the ...<B>Kurt,</B><BR/><BR/>if you pull from the packaging repo into the pristine repo, would the problem still happen?<BR/><BR/><B>Bryan:</B> you can add overflow by doing two things:<BR/><BR/>1) wrap a div tag around the table<BR/>2) add .post-body div { overflow: auto; }Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-19408088927711582682007-03-06T11:16:00.000-08:002007-03-06T11:16:00.000-08:00Hey,Definitely check out SVK.It's compatible with ...Hey,<BR/><BR/>Definitely check out SVK.<BR/><BR/>It's compatible with SVN, but gives you just about all of the features that the others packages provide.<BR/><BR/>With SVN compatability, you are able to mirror other open source repos on your local box. It's a very cool feature.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-20512890159216313882007-03-06T11:01:00.000-08:002007-03-06T11:01:00.000-08:00google darcs doppelganger. Look for "ICFP meetup n...google darcs doppelganger. Look for "ICFP meetup notes".<BR/><BR/>It's not a corner case if you are a package maintainer. Here's what happens:<BR/><BR/>1. Upstream distributes by tar.gz<BR/>2. You maintain the packaged source in a darcs repo. You find a bug, and send the patch upstream.<BR/>3. Upstream makes a new release incorporating your patch.<BR/>4. You maintain a darcs repo of the pristine upstream; you update this repro from the new tar.gz.<BR/>5. You pull from the pristine repo into your packaging repo.<BR/><BR/>You've just duplicated your patch. Darcs will probably lock up on the pull.<BR/><BR/>It can also happen if two developers make identical, but obvious, changes.KBKhttps://www.blogger.com/profile/15379134215192198434noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-40298668573835978082007-03-06T10:19:00.000-08:002007-03-06T10:19:00.000-08:00re: CSS...I would try:.post-body table { overflow:...re: CSS...<BR/><BR/>I would try:<BR/><BR/>.post-body table { overflow: auto !important; }<BR/><BR/>I personally use darcs; I chose it mostly because of the features you covered here, and the fact that it's entire manual is 1/10 the size of SVN's (the online O'Reilly book). I'm well aware of the 'serious bug', and recognize it for what it is: a corner case. I would be surprised if I got bit by it, as I don't share my darcs repo with other people, and that seems to be a requirement to trigger the bug. Most importantly, if it does lock up, you can kill the process without leaving your repo in an unknown state (based on what I was able to discover)<BR/><BR/>Therefore, *I* would suggest that people should give it a look, as long as they're aware of where it can fall down (and besides, it gets so many things *right*, it's hard for me to say 'stay away').Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-58489612546891228232007-03-06T10:12:00.000-08:002007-03-06T10:12:00.000-08:00while svn can't track rename itself, CL Kao's SVK ...while svn can't track rename itself, CL Kao's SVK tool can - and also enables local branches for offline commit and all sorts of other similar goodies. Since svn repos have become something of a lingua franca a lot of people are now using svn backend with svk on the frontend for OSS dev.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-88969583671890333242007-03-06T06:40:00.000-08:002007-03-06T06:40:00.000-08:00For the darcs issue:http://zooko.com/darcs_demysti...For the darcs issue:<BR/><BR/>http://zooko.com/darcs_demystified.html<BR/><BR/>Scroll down to the bottom half of the page. These are corner cases so are unlikely to occur.<BR/><BR/>That's all I can guess the author is referring to.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-22072658189915222712007-03-06T03:31:00.000-08:002007-03-06T03:31:00.000-08:00Two questions:1. Which version of Darcs did you us...Two questions:<BR/><BR/>1. Which version of Darcs did you use? The "last stable" 1.0.8 or the 1.0.9 release candidates (which I found to be much faster, esp. on binary files)<BR/><BR/>> Darcs still reportedly has a deep, serious bug.<BR/><BR/>Would it be possible to have more informations on that?Unknownhttps://www.blogger.com/profile/10261896483118253882noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-12451875020380005652007-03-06T02:30:00.000-08:002007-03-06T02:30:00.000-08:00Do you have some more details on the claim "Darcs ...Do you have some more details on the claim "Darcs still reportedly has a deep, serious bug. Don’t use it (though it is nice)"?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-17171290621818760832007-03-05T07:57:00.000-08:002007-03-05T07:57:00.000-08:00Thank you for your comment. I'm glad that you've ...Thank you for your comment. I'm glad that you've pointed out a couple more efficient ways to use git. I hope to see more advice and corrections in the comments here.<BR/><BR/>I almost didn't put in the timing comparison because it is really dependent on what the setup and development model of your project is. What if you really need to do a lot full repository clones? What if you need to do a lot of clones over the network? What if you don't plan on doing much branching at all? That's why this kind of timing comparison is almost always bogus.<BR/><BR/>That being said, the final column of my timing table is the simple sum of all the other times for each too.. Mercurial's total was smallest, and that's why I declared it winner. It just so happens that if you completely throw out git's clone and merge times, it's still slower than hg.<BR/><BR/>But please remember, that's just for this particular setup on my particular machine.Bryanhttps://www.blogger.com/profile/11394436715172971234noreply@blogger.comtag:blogger.com,1999:blog-3669809752172683097.post-5669206073528851102007-03-04T10:30:00.000-08:002007-03-04T10:30:00.000-08:00In git, creating a branch and cloning the reposito...In git, creating a branch and cloning the repository are not the same thing. You create a branch with git checkout -b branchname. That writes one small value to storage, and that takes virtually no time. And for faster local cloning, use git clone -l. If you also want to use the base object store as a reference, use git clone -l -s, but take care when pruning the original store.<BR/><BR/>As usual, the person crowing about high-level languages doesn't know what's going on beneath the hood, and so doesn't know that the timing comparison is bogus. ;)Anonymousnoreply@blogger.com