Mercurial > CVu-Mercurial

comparison Hg.txt @ 7:8660df02d8a9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
More subediting.
author Jim Hague <jim.hague@acm.org>
date Tue, 31 Mar 2009 12:09:11 +0100
parents a942bf7bc2ab
children abca12aaa38d
comparison
equal deleted inserted replaced
6:a942bf7bc2ab 7:8660df02d8a9
73 yourself. There was also a lack of Windows support for Git at the 73 yourself. There was also a lack of Windows support for Git at the
74 time. 74 time.
75 75
76 o Speed. Mercurial is fast. In the same ballpark as Git. Bazaar 76 o Speed. Mercurial is fast. In the same ballpark as Git. Bazaar
77 wasn't, and although it has improved significantly, has, in my 77 wasn't, and although it has improved significantly, has, in my
78 estimation, added user complexity in the process, and is still off the 78 estimation, added user complexity in the process, and at the time
79 pace for some operations. 79 of writing is still off the pace for some operations.
80 80
81 o Documentation. At the time, Bryan O'Sullivan's excellent Mercurial 81 o Documentation. At the time, Bryan O'Sullivan's excellent Mercurial
82 book (http://hgbook.red-bean.com) was a clear winner for best 82 book (http://hgbook.red-bean.com) was a clear winner for best
83 documentation. 83 documentation.
84 :::: 84 ::::
196 directory a file occupies is tracked, but effectively only as a 196 directory a file occupies is tracked, but effectively only as a
197 component of the file name. This has the slightly unexpected result 197 component of the file name. This has the slightly unexpected result
198 that you can't record an empty directory in your repository. 198 that you can't record an empty directory in your repository.
199 199
200 (Footnote: I tripped over this converting a work Subversion 200 (Footnote: I tripped over this converting a work Subversion
201 repository. One possibility is to create a placemaker file in the 201 repository. One possibility is to create a placeholder file in the
202 directory. In the event I created the directory (which receives build 202 directory. In the event I created the directory (which receives build
203 products) as part of the build instead.) 203 products) as part of the build instead.)
204 204
205 Given this, and the status output above that suggests strongly that 205 Given this, and the status output above that suggests strongly that
206 Mercurial treats a rename as a copy followed by a delete, you may be 206 Mercurial treats a rename as a copy followed by a delete, you may be
303 you use 'bzr revert -r' to bring the working copy to a past revision, 303 you use 'bzr revert -r' to bring the working copy to a past revision,
304 make a change and commit, then your latest version will be the past 304 make a change and commit, then your latest version will be the past
305 revision plus your change. Perhaps that's what Mercurial did? 305 revision plus your change. Perhaps that's what Mercurial did?
306 306
307 No. What Mercurial did is central to Mercurial's view of the 307 No. What Mercurial did is central to Mercurial's view of the
308 world. You took your working copy back to an old changeset, and the 308 world. You took your working copy back to an old changeset, and then
309 committed a fresh change based at that changeset. Mercurial actually 309 committed a fresh change based at that changeset. Mercurial actually
310 did just what you asked it to do, no more and no less. Let's see the 310 did just what you asked it to do, no more and no less. Let's see the
311 initial evidence. 311 initial evidence.
312 312
313 $ hg heads 313 $ hg heads
484 484
485 That's simple, as in 'most things are simple once you know the 485 That's simple, as in 'most things are simple once you know the
486 answer'. I found the explanation helpful, so this section attempts 486 answer'. I found the explanation helpful, so this section attempts
487 the 10,000ft (FL100 if you prefer) view of Mercurial. 487 the 10,000ft (FL100 if you prefer) view of Mercurial.
488 488
489 (Foornote: Bryan O'Sullivan's excellent Mercurial book has a chapter 489 (Foornote: For the curious, Bryan O'Sullivan's excellent Mercurial book
490 on the subject, and the Mercurial website has a fair amount of detail 490 has a chapter on the subject, and the Mercurial website has a fair amount
491 too. This is 'research', OK?) 491 of detail too.)
492 492
493 First remember that any file or component can only have one or two 493 First remember that any file or component can only have one or two
494 parents. You can't merge more than one other branch at once. 494 parents. You can't merge more than one other branch at once.
495 495
496 We start with the basic building block, which Mercurial calls a 496 We start with the basic building block, which Mercurial calls a
632 identifier and resolving parallel development by merges between 632 identifier and resolving parallel development by merges between
633 overlapping changes is the same. And all three can be used in a truly 633 overlapping changes is the same. And all three can be used in a truly
634 distributed manner, with full history and the ability to commit being 634 distributed manner, with full history and the ability to commit being
635 available locally. 635 available locally.
636 636
637 I want now to reflect on the consequences all this has for that 637 So instead of chatter on about workflows, I want instead to reflect on
638 all-important question of whether a DVCS is a suitable vehicle for 638 the consequences all this has for that all-important question of
639 your data. 639 whether a DVCS is a suitable vehicle for your data.
640 640
641 The first is a minor and rather obvious point. If you want to store 641 The first is a minor and rather obvious point. If you want to store
642 files that are both very large and which change often in your DVCS, 642 files that are very large and which change often in your DVCS, then
643 then all the compression in the world is unlikely to stop the storage 643 all the compression in the world is unlikely to stop the storage
644 requirements for the full project history from becoming 644 requirements for the full project history from becoming uncomfortably
645 uncomfortably large. 645 large, particularly if the files are not very compressible to start
646 with.
646 647
647 The second, and main, point is that there is an important question you 648 The second, and main, point is that there is an important question you
648 need to ask about your data. We've seen that a DVCS relies on 649 need to ask about your data. We've seen that a DVCS relies on
649 branching and merging to weave its magic. So take a close look at your 650 branching and merging to weave its magic. So take a close look at your
650 data, and ask: 651 data, and ask: