[darcs-users] revision identifiers

[Declan Naughton]

On Thu, Mar 27, 2008 at 5:16 AM, Max Battcher <me at worldmaker.net> wrote:
>
> Declan Naughton wrote:
>  > In revision control systems like Mercurial and git, every time the
>  > repository is updated (recorded to in darcs terms) a new revision
>  > identifier is associated with it's new state, so that it can be
>  > referred to for checkouts and such.
>  >
>  > In darcs, users MUST MANUALLY use tags, this I consider quite a
>  > downfall. Would it be a bad or a good idea for darcs to checksum the
>  > context and record this with records, and, (being the revision
>  > identifier) printing this out in 'darcs changes', providing for 'darcs
>  > get --rev=xxxxxxxxx' etc?
>  >
>  > Or what am I overlooking?
>
>  Generally the consensus is that the distributed nature of darcs, plus
>  the ability to cherry-pick individual patches, doesn't lend itself to
>  useful universally unique numbers for revisions.  Various non-universal
>  numbering schemes have been suggested, but thus far none have been
>  implemented.  (Some have even suggested automagic tagging to some extent
>  or another.  You could write an external script to do something of that
>  sort if you really wanted... but said script would probably be better
>  off recording useful context files and leaving tags for meaningful states.)
>
>  Anyway, the easiest way to say "here's a specific non-tagged version of
>  the repository that I want you to get" in darcs is to pass along a
>  context file (the output of ``darcs changes --context``) and you can
>  ``darcs get remote:repo --context=some/file.context``.  Context files
>  are also very useful when repositories cannot directly communicate
>  (firewall, etc) but need to share states so that patches can be emailed
>  back and forth.  Context files are very much a darcs developers' best
>  friend for communicating repository state and I don't think sending a
>  simple context file is any more/less confusing/complicated/tough than
>  trying to copy and paste some arbitrary n-digit numeral.  Maybe I'll
>  write an article on my impressions of Darcs and Context files versus Tags...
>
>  More ways of getting other developers to specific states is to focus on
>  good patch style.  Patches should be reasonably "atomic" (do what they
>  say they do, contain everything needed or directly depend on anything
>  not included), which is something often preached by all VCSes, but Darcs
>  generally rewards good behavior a bit better than most.  Darcs offers a
>  number of ways to say get me "patch x" and everything it depends on, and
>  if things are reasonably atomic, that takes care of 80% of your needs to
>  jump to a specific "revision".  If your patches have generally
>  informative names and comments you can do that very well with darcs'
>  interactive push/pull.  Memorable patch names can be searched for by
>  command line with regexes and there is a "universally unique" hash
>  identifier for every patch if you want a very specific command line that
>  can be copy and pasted.
>
>  Tags are indeed the way to name a specific collection of patches and
>  there is basically no overhead for tags and creating a new tag takes
>  only time to name it, so I don't see manually "required" tags as that
>  much of a downfall anyway.
>
>  --
>  --Max Battcher--
>

I think the power that darcs allows in cherry-picking is wondrous, but
don't you think it lets itself down to newcomers because it's so much
more of a task to simply get a specific revision on which to build
compared with Hg and git? They will need to get the tag previous to
the revision they want, and then 'darcs pull' and run through the
patches (unless the revision is tagged, which I guess would be most
common, but still). This is more flexible (and extremely useful. Since
darcs is available with this power, I'm trying to consider only this,
and I think that's why it needs to focus on usability and
documentation, because it's easy to just fuck darcs off and use Hg),
but I think it's a fairly common use case to wish to reproduce a
revision without any differences to how the repository produced it,
and therefore revision identifiers like Hg and git use would be useful
(even if only slightly after users become more adept) as well as
context files.

Consider how daunting it is for a Hg user trying to grasp darcs to run
'darcs changes' and find absolutely no identifier to jump back to a
mildly-old version of the repository... (something about unrecord
frightens me, but do explain how it can/can't be used if it would
help)

Why can't checksumming the context produce a suitable identifier, I
must ask? What are the uses in it being "universally unique" that we
would miss out on, anyhow? We can still seek through the repository
history and get specific revisions?

-- 
Declan Naughton