[darcs-users] revision identifiers

Fri Mar 28 22:51:31 UTC 2008

Excerpts from Declan Naughton's message of Fri Mar 28 17:26:27 +0100 2008:
> 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?

Also  remember  that  context stops at tags. So, if you've tagged recently the
context will be quite small.

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080328/987eaf44/attachment.pgp 