Trent W. Buck writes: > "Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > > YMMV, but in my experience (a) communication of the patches per se is > > only an issue the first time I set up a branch, after that local > > branches are cheap (though still way expensive compared to git or > > Mercurial) > > Even though you're using hard-linking with ~/.darcs/cache ?
Even hard links take human-perceptible time if you have to do a couple thousand of them. In git, "echo $SHA1 > .git/refs/heads/mybranch" creates a branch. Mercurial branches require that you actually have hg installed ;-), but they are also just a reference to a revision. The only difference from a tag is in the code: tag refs are never updated (even the user has to say --force to do it), while the current branch ref is automatically updated to point to the current revision at record time. Darcs could probably implement cheap in-repo branches using the existing low-level machinery of dependencies, but it would be a hack and would also probably complicate the implementation of the mainline branch. > What do hg and git do differently that makes their local branching > cheaper? Simply because it's done within a single repo, and therefore > you only ever have one copy of the working tree? "Ever" is too strong, but "few workspaces" is important to me, yes, though YMMV. Darcs branches are also conceptually expensive because I have to decide where to put them, and I have to remember where they are when I want to refer to them. On my own git/hg projects I often make, push, and abandon as many as a dozen topic branches (for correcting typos and the like discovered on a working branch) in a couple hours. This process is easily automated and costs *less* time to me than Emacs autosaves do. I can't imagine trying that with Darcs. (That is, using branches. In Darcs of course you'd just record the patch and cherrypick it. I don't like reading logs with lots of out-of-task patches, though, and in git/hg the "microbranch" approach gives me that.) > > But for the fountain code to have much impact on a day-to-day basis, > > you'd need to ensure that several fairly up-to-date mirrors are > > available all the time. Somebody has to admin those hosts and > > maintain those mirrors. > > The buildbots already do most of this; is it feasible to have them > export their local mirrors of the darcs repository? Now, that's a good idea. It might take some work to implement robustly, and of course buildbot owners might take exception to providing the bandwidth (remember, since it's automated, they'll get slashdotted by announcements on darcs-users). But I see no reason why it wouldn't work, and some form of throttling would be an answer to the bandwidth problem while still improving availability. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
