On Wed, Aug 26, 2009 at 9:24 AM, Simon Michael<[email protected]> wrote: > Yes. A good article, but I can't make sense of the three paragraphs where he > talks about darcs.
It took me a while to read the whole thing, but I've finally finished. What I like about this article is that it tells us what are the great features of other vcs. Which I see as an opportunity for inspiration and refinement. I like this paragraph: For an example of novel publication, Mercurial supports ad hoc publication of repositories over a LAN using its built-in Web server, and it supports discovery of repositories using the Bonjour protocol. This is a potent combination for rapid development settings such as a software project's sprint: just open your laptop, share your repositories, and your Wi-Fi neighbors can find and pull your changes immediately, with no server infrastructure required. That's a pretty cool feature. Darcs should borrow this cool idea! Ad-hoc networks to share patches. This paragraph was interesting to me as well: Both Mercurial and Git decouple fetching remote changes from merging them with local changes. If Bob fetches Alice's revisions, he can still commit his changes without needing to merge with hers first. When he merges afterward, he will still have a permanent record of his committed changes. If the merge runs into trouble, he will be able to recover his earlier work. It sounds to me like, darcs partially decouples this. It merges them in and keeps them separate, but it does so over top of your working copy. So if you have something you're working on it could get conflict markers over top of it. Or if files you are working with are renamed it could be confusing too. In darcs, I think the best practice is to record your local changes first. Perhaps we should consider refining darcs's UI in this case. For example, what if darcs could warn you when you have unrecorded changes locally before allowing you to pull in new changes? Here is an example to illustrate my point using a mocked up session: darcs pull foo Unrecorded local changes detected. How to proceed? [i,r,q,?] ? i: ignore the unrecorded changes and proceed with the pull. r: record the changes first and then proceed with the pull (Note: You will be able to unrecord or amend-record your changes later.) q: quit ?: help With a corresponding --dont-warn-unrecorded that can be set in the user's defaults for scripts and people who think this feature is obnoxious. There could be other annotations explaining why it's a good idea to record the changes first also: Unrecorded local changes detected. Pulling patches will merge the changes over your working copy. If you record your local changes first it will be easier to separate them from the new updates later, especially if there are conflicts. How to proceed? [i,r,q,?] Jason _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
