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 <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
