[darcs-users] some darcs comments from Johan Tibell

Johan Tibell johan.tibell at gmail.com
Sun Dec 27 13:16:07 UTC 2009


Hi,

Please CC me on any replies as I'm not on this mailing list. I just
found four replies than had gone unnoticed to me.

> Eric Kow <ko... at darcs.net> writes:
>
>> he [wants] make-me-a-branch command [to be] near instantaneousness.
>
> Doing the operation on the fileserver (instead of over NFS), branching
> is fast enough for me.  With the Darcs repository:
>
>     $ time ssh fs darcs get --lazy $PWD $PWD+issue1234
>     Copying pristine 286/508 : dist-v.sh
>     Finished getting.
>
>     real    0m1.157s
>     user    0m0.010s
>     sys     0m0.020s
>
>     $ du -sh $PWD $PWD+issue1234
>     52M     /home/twb/Desktop/Darcs/darcs
>     4.7M    /home/twb/Desktop/Darcs/darcs+issue1234

This does not include changing to the new working directory. Is it
best practice to create your topic branches inside the directory of
the main branch as done in this case?

Also it doesn't have quite the same effect. When checking out a new
branch in Git using "git checkout -b" untracked/uncommited files are
still present in the working directory of the new branch, meaning that
if you created a new file while working on e.g. the master branch and
then realized that you want to commit them on a new branch you don't
have to manually move them. This also means that already compiled
files in dist/ (created by Cabal) can be more easily shared between
branches.

> fs runs Fedora Core 3 and has two SATA disks in a software RAID 1 array.
> I can only assume that when people complain about slow branch creation
>
>     - they're *really* impatient;
>     - they're using NFS on 100baseT (like me);

This is on local disk.

>     - they're still using old-fashioned-inventory repos;
>     - they're not using --lazy for branches;

Aside: I want all my history locally so I don't use lazy. I remember
back when that feature was announce and it didn't make any sense to me
back then. Would severely increase the variability in execution times
of different commands? There's lots of research showing that high
variability is even worse than consistently slow operations when it
comes to user perceived latency. What about when I'm on a plane?

>     - they're not using hard linking; or

I believe I'm using hard links as it's the default.

>     - they're using HUGE repositories.

Why assume when you can ask? The research I've seen done at Google
shows that humans perceive events as being instantaneous if they're
shorter than about 250ms and that one can measure statistically
significant difference in behavior for every 100ms slower than 250ms.
The area of research wasn't VCSs (it was web search) but I feel
confident that the effects translate. There are also anecdotal
evidence from Git users describing that they use their system
differently when certain operations are faster.

>> Johan Tibell writes:
>
>>> $ git diff master..integration  # All changes taken together to get an
>>> overview
>>> $ git diff integration~2..integration~3  # Patch 3 (newest)
>
> Isn't the latter equivalent to the simpler "git show integration~3"?

I use an external diff tool.

>>> Random other things I miss:
>>> * Being able to easily refer to any patch -- typing a regex the
>>> matches the commit messages uniquely is a pain. So is counting
>>> backwards (i.e. --last=54.)
>
> What's git's "easy" way to uniquely refer to a patch?  Hashes?  Darcs
> has --match 'hash XXX'.

The hashes in Git are used everywhere so you're likely to have the
hash available (further up in your terminal screen) when you need it.
The same cannot be said about Darcs' hashes.

>>>   * Not when typing "darcs help". You want the help text to stay when
>>>     you're looking for command line flags to give to a command! The
>>>     pager makes the help text disappear when you're supposed to type
>>>     the command.
>
> I think this is just git setting $LESS to FSR (unless it's already set
> to something else).  The help text "disappears" because your terminal
> emulator has been configured that way.  Try ^A:altscreen off in GNU
> Screen -- I dunno about other terminals.  LESS=F should help if you use
> less.

I don't want to change the default behavior of less for all uses. Can
I have it do this just for darcs?

Cheers,

Johan


More information about the darcs-users mailing list