Hi, One question which came up: what's the different between staging commits with an index, and staging with darcs amend-record?
On Sun, Dec 27, 2009 at 14:16:07 +0100, Johan Tibell wrote: > This does not include changing to the new working directory. Is it > best practice to create your topic branches inside the directory of > the main branch as done in this case? For small projects, I tend to have a single directory in which I dump all my repositories: hacking/chart-parser hacking/chart-parser-foo hacking/lingscore hacking/lingscore-bob But for larger projects, I tend to have a single directory just for that project darcs-hacking/unstable darcs-hacking/kowey darcs-hacking/review-291 (so cd darcs-hacking; darcs get --lazy http://darcs.net review-291) > Also it doesn't have quite the same effect. When checking out a new > branch in Git using "git checkout -b" untracked/uncommited files are > still present in the working directory of the new branch, meaning that > if you created a new file while working on e.g. the master branch and > then realized that you want to commit them on a new branch you don't > have to manually move them. This also means that already compiled > files in dist/ (created by Cabal) can be more easily shared between > branches. It sounds like a fairly convincing argument that in-repo branches are useful because a single, shared working directory (across branches) is useful. Now, the wider context is that YES, there is interest in implementing in-repo branches <http://bugs.darcs.net/issue555>, but there is some debate about the right way to do it. My main worry (personally) is losing the simplicity of Darcs, which I think is a quality that we should hang to very tenaciously. I just had a thought on one principle we could adopt that could help us preserve this simplicity. Johan: since you're an active user of branches, could you comment on the following idea? Darcs should never implement 'remote' branches. Branches should be strictly a personal affair, something a hacker would use to work on multiple features at the same time, or a maintainer to keep track of a bunch different patch sets; but NOT for a project that wants to publish multiple branches (they'd have to do it the old fashioned way). Perhaps this sort of simplifying principle will help. Basically the idea is that we should consider making a point of not EVER implementing (a) copying of branches and (b) pushing to and pulling from branches in other repos. That branches be tied to a single directory may allow us to make life more convenient for the most common use cases while keeping Darcs simple to use and think about. > > fs runs Fedora Core 3 and has two SATA disks in a software RAID 1 array. > > I can only assume that when people complain about slow branch creation > > > > - they're *really* impatient; > > - they're using NFS on 100baseT (like me); > > This is on local disk. Trent: any ideas on what's going on here? Is there some good reason for this sort of discrepancy if any? > > - they're not using --lazy for branches; > > Aside: I want all my history locally so I don't use lazy. Even when branching an already local repo? What's there to lose? > I remember back when that feature was announce and it didn't make any > sense to me back then. Would severely increase the variability in > execution times of different commands? There's lots of research > showing that high variability is even worse than consistently slow > operations when it comes to user perceived latency. I recommend just trying this to see how it feels. So I think what makes --lazy work well in practice is that in practice, one does not actually consult the patches that are far back in history very often. If they do, it causes some fetching but only once. So I don't think this sort of thing really constitutes high variability: fast fast fast fast SLOW fast fast fast I think it would make sense to try it and see how it feels in practice, see what life is like with some lazy repos. If you're on a plane, you lose the ability to view the contents of a patch that you don't have, but is that really such a huge cost compared to the one you pay more frequently? > What about when I'm on a plane? Well you lose the ability to consult the patches that are far back in history... if you're on a plane. > Why assume when you can ask? The research I've seen done at Google > shows that humans perceive events as being instantaneous if they're > shorter than about 250ms and that one can measure statistically > significant difference in behavior for every 100ms slower than 250ms. > The area of research wasn't VCSs (it was web search) but I feel > confident that the effects translate. There are also anecdotal > evidence from Git users describing that they use their system > differently when certain operations are faster. I think it's a good goal for the future. For now, we're focused on fixing the more egregious issues like things taking many seconds or even minutes that should be faster. If we can knock a lot of these issues out (eg. implement filecache so that darcs annotate is usably fast, making darcs get fast over a network, making darcs not keel over and die if you try to record too large a patch), then we can start to worry about instantaneous operations. So I'm agreeing with you here, but I'm just pointing out that we are working on lots of different ways to make Darcs faster > >> Johan Tibell writes: > > > >>> $ git diff master..integration # All changes taken together to get an > >>> overview > >>> $ git diff integration~2..integration~3 # Patch 3 (newest) > > > > Isn't the latter equivalent to the simpler "git show integration~3"? > > I use an external diff tool. To diff across branches in the current setup, you'd just use that external diff tool without any darcs commands. To diff across versions, there is now an --index=N-M flag... which unfortunately is broken at the moment http://bugs.darcs.net/issue1290 But once that works again, I think it'd be the same feature. > >>> Random other things I miss: > >>> * Being able to easily refer to any patch -- typing a regex the > >>> matches the commit messages uniquely is a pain. So is counting > >>> backwards (i.e. --last=54.) > > > > What's git's "easy" way to uniquely refer to a patch? Hashes? Darcs > > has --match 'hash XXX'. > > The hashes in Git are used everywhere so you're likely to have the > hash available (further up in your terminal screen) when you need it. > The same cannot be said about Darcs' hashes. So would a good default be for darcs changes to always print out the patch-info hash for each patch? Mon Dec 14 14:37:41 GMT 2009 Ganesh Sittampalam <[email protected]> hash: 20091214143741-81bb2-9725f2de882a5c58c6a1980562c841a8eb9cfb19 * fill out witnesses.hs This just adds all modules to the list imported by witnesses.hs either directly or indirectly, with some imports commented out since the modules don't work with witnesses yet. The idea is to make it easier to see what hasn't had witnesses added yet. Sat Dec 26 20:24:45 GMT 2009 Joachim Breitner <[email protected]> hash: 20091226202445-23c07-b969b8ccc862c63d3317b0652415604f30049830 * Also import (<>) Thu Dec 24 11:34:44 GMT 2009 Joachim Breitner <[email protected]> hash: 20091224113444-23c07-5bd7128afb3ad9a32c49e59f4f5fdfc5db05eb88 * Resolve issue1362: Mention repo name in mail send body > >>> * Not when typing "darcs help". You want the help text to stay when > >>> you're looking for command line flags to give to a command! The > >>> pager makes the help text disappear when you're supposed to type > >>> the command. > > > > I think this is just git setting $LESS to FSR (unless it's already set > > to something else). The help text "disappears" because your terminal > > emulator has been configured that way. Try ^A:altscreen off in GNU > > Screen -- I dunno about other terminals. LESS=F should help if you use > > less. > > I don't want to change the default behavior of less for all uses. Can > I have it do this just for darcs? Maybe DARCS_PAGER will help (environment variables notwithstanding, I do agree that we need to do something about the pager defaults: http://bugs.darcs.net/issue896 -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpkwyFt8deoS.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
