patch, match, matches

I sometimes wonder if we should simplify the patch matching interface, or at least document fewer commands. At the very least, it seems we could just nix --patch altogether and replace it by --match='name Foo'.

Also, maybe we should just get rid of the distinction between singular and plural forms. --match should just match everything, and the --last should be used to select among these matches. In fact, I think that's how it already behaves, and that the doc is just a little bit out of date.

Finally, I would even be tempted to get rid of --tag (and likewise --from-tag, --to-tag), and just implement something like --match='tag '.

I suppose we could keep around the old flags for users who are accustomed to them (although I doubt people would really miss them...) and just simplify the documentation.

I sometimes wonder if we should simplify the patch matching interface, or at least document fewer commands. At the very least, it seems we could just nix --patch altogether and replace it by --match='name Foo'.

Also, maybe we should just get rid of the distinction between singular and plural forms. --match should just match everything, and the --last should be used to select among these matches. In fact, I think that's how it already behaves, and that the doc is just a little bit out of date.

Finally, I would even be tempted to get rid of --tag (and likewise --from-tag, --to-tag), and just implement something like --match='tag '.

I suppose we could keep around the old flags for users who are accustomed to them (although I doubt people would really miss them...) and just simplify the documentation.

patch, match, matches

Arrrrghhh

I just spent today debugging some ssh stuff with a user. Oh man. It seems like everytime I submit a patch, I have to submit ten other patches afterwards to correct bugs in my first patch, and bugs in my bugfixes.

I just spent today debugging some ssh stuff with a user. Oh man. It seems like everytime I submit a patch, I have to submit ten other patches afterwards to correct bugs in my first patch, and bugs in my bugfixes.

Arrrrghhh

query cat

Did I just promise to implement 'darcs query cat'? Gah, no, bad eric! Extra commitments bad! The most surefire way to break your current promises is take on new ones. It should be easy though. But you know it goes when you say stuff like that...

Did I just promise to implement 'darcs query cat'? Gah, no, bad eric! Extra commitments bad! The most surefire way to break your current promises is take on new ones. It should be easy though. But you know it goes when you say stuff like that...

query cat

updated images

On a random burst of inspiration, I have finally gotten around to updating the images used in Understanding Darcs. They include some ideas from #darcs, namely Heffalump's suggestion that I colour the _darcs stuff differently than the working dir. Also, I have uploaded the Omnigraffle sources for these diagrams so that you can look at it and go "Ugh! XML!", or open it on your Mac.



Yeah, yeah, I know I should be using something Free-er like Inkscape... but Omnigraffle, man... it's so fantastically easy to use! Aack, no! There I go, I'm promoting non-free software... Nooooo (well then again, I'm still addicted to the comfort of my Mac, though Ubuntu's looking better and better these days, so I'm pretty much screwed for ideology in either case)

See, this is the kind of stuff I should be working in my free time when I'm looking for something easy. Much more constructive, and even massages the creative juices a tiny bit, much better than, say, going on a 16 hour Freeciv binge... which isn't something I would... actually... do... of course.

Updated again - 23:20

Another update, 8 hours later. This time, went for a model which makes it possible to represent everything in one picture (instead of having a before/after comparison).

That speeds up my diagram-development time considerably. It's already pretty smooth sailing, thanks to layers, but having half as many layers as before is always welcome.



Also added diagrams for revert, unrecord, obliterate.

Anyway, I'd better not get too eager about this book. I do have real work to do, after all. Also, a few diagrams by themselves probably isn't going to make things that much easier for the user. We'll need actual examples, and probably a patient walkthrough, something which I probably do not have the energy to do.

On a random burst of inspiration, I have finally gotten around to updating the images used in Understanding Darcs. They include some ideas from #darcs, namely Heffalump's suggestion that I colour the _darcs stuff differently than the working dir. Also, I have uploaded the Omnigraffle sources for these diagrams so that you can look at it and go "Ugh! XML!", or open it on your Mac.



Yeah, yeah, I know I should be using something Free-er like Inkscape... but Omnigraffle, man... it's so fantastically easy to use! Aack, no! There I go, I'm promoting non-free software... Nooooo (well then again, I'm still addicted to the comfort of my Mac, though Ubuntu's looking better and better these days, so I'm pretty much screwed for ideology in either case)

See, this is the kind of stuff I should be working in my free time when I'm looking for something easy. Much more constructive, and even massages the creative juices a tiny bit, much better than, say, going on a 16 hour Freeciv binge... which isn't something I would... actually... do... of course.

Updated again - 23:20

Another update, 8 hours later. This time, went for a model which makes it possible to represent everything in one picture (instead of having a before/after comparison).

That speeds up my diagram-development time considerably. It's already pretty smooth sailing, thanks to layers, but having half as many layers as before is always welcome.



Also added diagrams for revert, unrecord, obliterate.

Anyway, I'd better not get too eager about this book. I do have real work to do, after all. Also, a few diagrams by themselves probably isn't going to make things that much easier for the user. We'll need actual examples, and probably a patient walkthrough, something which I probably do not have the energy to do.

updated images

ssh does indeed invoke a shell

And so continues our saga of Eric Doesn't Actually Know How Computers Work...

New discovery of the day? SSH does indeed invoke a shell when you do something like ssh myserver mycommand I always somehow figured that when you did that, magically mycommand would be invoked, like really first thing when you log in, no shell or nuthing. Nope, that's not how it works, and come to think of it, that kinda makes sense, right, because the computer gets to enforce what the user runs when (s)he logs in (duh). If it didn't go through a shell, then what would be the point of having that bit in /etc/passwd that tells the computer what shell to run? The user could totally bypass that by saying ssh myserver /launch/ze/missles. Oh wait... then again, maybe it's not for security reasons, because the user wouldn't have +x on /launch/ze/missles (but I am le tired!)... ugh, it's late, and the later it gets the more easily I confuse myself. Ok, so point being, ssh invokes a shell when you try to launch a command through it. Check.

Makes my issue223 kinda redundant, then, don't it?

the wikibook

Oh, and a minor note, I have slightly fleshed out the Understanding Darcs wikibook. Now, you might think that having a wikibook is redundant with either the Darcs manual, or the Darcs wiki, or both, but I would tend to disagree. I'd like you first of all to think of the wikibook not as a Wiki, but a Book. See, we got three things here, a Manual, a Wiki and a Book.

The way I figure, a Manual's job is to be terse and complete. It needs to be a good reference guide, the kind of thing that mechanics can thumb through without wading through a bunch of useful "helpful" stuff. The K+R book is what comes to mind when I think of this. No nonsense, here's everything you need to know. Of course, a Manual can be friendly if it wants, but only as long as said friendliness does not get in the way of its core mission, thumb-through-ability.

Now what's a software Wiki's job? Not to be friendly either! I'm not sure what I'd put down as its core mission, because you know, if anything wikis are meant to be chaotic and messy. No more than neccesary, of course; it's always nice to have someone come in and try to sweep things around and put things in their place. I guess if anything, a Wiki's core mission is to cover the fokelore. In fact, let's not call it Wiki anymore. Abstract over the fact that it's a wiki. A Folklore Repository is meant to know everything that the community knows. It can be friendly if the community is feeling friendly, but really, its main role is sprawl out into all the little niches of Our knowledge (and that's why wikis are ideal for this, because every one of Us can go plug something in).

And now we get to a Book. What's a Book supposed to do (I should call it something else, like a Guide). So scratch that. What's a Guide supposed to do? Be friendly. And that's we don't have yet in the darcs community. We've got the Manual covered (and we rock because our comments are our manual, go David!). We've got the Folklore down, but not alot of Folk and thus, not a lot of lore. But what we're sorely, sorely missing is an actual Guide. And this is where wikibooks comes in. Hyper-text is nice and all, but one thing which makes a document friendly, I think, is it doesn't force you to choose anything. Not even the order that you read stuff. No a Guide should really be telling you, look, ok, of course you can approach this any way you want, but if you listen to the way I tell it, if you follow me, I will tell you a coherent story. I might be full of crap about this, but in order to make a Guide work, you have to make it sequential. Point being, a Guide needs to be a book, not a wiki. You can put hypertext in it to make it richer, but there must be a canonical order for users to fall back on. Of course, then why use wikibooks? Because I want to author this with the community. I don't think I can pull it off myself. What we're producing is not a real Guide, but sort of a compromise between Folklore and a Guide. But then... why Wikibooks? Why not just put the Guide on the darcs wiki? Oh technical reasons. MoinMoin isn't the easiest thing to work with for fancy stuff. I wish there was a latex-based wiki out there. Like good. Well, actually, there's another part to that, in that I want it on wikibooks, because I want editors to look at that thing and think Book (not Wiki). Book as in, let me try to be pedagogical. Not Wiki as in, let me slap down what I know any old way.

There ya go. Three paragraphs of rambling nonsense with Capital Letters liberally sprinkled throughout. I'd better go home and try to do something useful with my time instead.

And so continues our saga of Eric Doesn't Actually Know How Computers Work...

New discovery of the day? SSH does indeed invoke a shell when you do something like ssh myserver mycommand I always somehow figured that when you did that, magically mycommand would be invoked, like really first thing when you log in, no shell or nuthing. Nope, that's not how it works, and come to think of it, that kinda makes sense, right, because the computer gets to enforce what the user runs when (s)he logs in (duh). If it didn't go through a shell, then what would be the point of having that bit in /etc/passwd that tells the computer what shell to run? The user could totally bypass that by saying ssh myserver /launch/ze/missles. Oh wait... then again, maybe it's not for security reasons, because the user wouldn't have +x on /launch/ze/missles (but I am le tired!)... ugh, it's late, and the later it gets the more easily I confuse myself. Ok, so point being, ssh invokes a shell when you try to launch a command through it. Check.

Makes my issue223 kinda redundant, then, don't it?

the wikibook

Oh, and a minor note, I have slightly fleshed out the Understanding Darcs wikibook. Now, you might think that having a wikibook is redundant with either the Darcs manual, or the Darcs wiki, or both, but I would tend to disagree. I'd like you first of all to think of the wikibook not as a Wiki, but a Book. See, we got three things here, a Manual, a Wiki and a Book.

The way I figure, a Manual's job is to be terse and complete. It needs to be a good reference guide, the kind of thing that mechanics can thumb through without wading through a bunch of useful "helpful" stuff. The K+R book is what comes to mind when I think of this. No nonsense, here's everything you need to know. Of course, a Manual can be friendly if it wants, but only as long as said friendliness does not get in the way of its core mission, thumb-through-ability.

Now what's a software Wiki's job? Not to be friendly either! I'm not sure what I'd put down as its core mission, because you know, if anything wikis are meant to be chaotic and messy. No more than neccesary, of course; it's always nice to have someone come in and try to sweep things around and put things in their place. I guess if anything, a Wiki's core mission is to cover the fokelore. In fact, let's not call it Wiki anymore. Abstract over the fact that it's a wiki. A Folklore Repository is meant to know everything that the community knows. It can be friendly if the community is feeling friendly, but really, its main role is sprawl out into all the little niches of Our knowledge (and that's why wikis are ideal for this, because every one of Us can go plug something in).

And now we get to a Book. What's a Book supposed to do (I should call it something else, like a Guide). So scratch that. What's a Guide supposed to do? Be friendly. And that's we don't have yet in the darcs community. We've got the Manual covered (and we rock because our comments are our manual, go David!). We've got the Folklore down, but not alot of Folk and thus, not a lot of lore. But what we're sorely, sorely missing is an actual Guide. And this is where wikibooks comes in. Hyper-text is nice and all, but one thing which makes a document friendly, I think, is it doesn't force you to choose anything. Not even the order that you read stuff. No a Guide should really be telling you, look, ok, of course you can approach this any way you want, but if you listen to the way I tell it, if you follow me, I will tell you a coherent story. I might be full of crap about this, but in order to make a Guide work, you have to make it sequential. Point being, a Guide needs to be a book, not a wiki. You can put hypertext in it to make it richer, but there must be a canonical order for users to fall back on. Of course, then why use wikibooks? Because I want to author this with the community. I don't think I can pull it off myself. What we're producing is not a real Guide, but sort of a compromise between Folklore and a Guide. But then... why Wikibooks? Why not just put the Guide on the darcs wiki? Oh technical reasons. MoinMoin isn't the easiest thing to work with for fancy stuff. I wish there was a latex-based wiki out there. Like good. Well, actually, there's another part to that, in that I want it on wikibooks, because I want editors to look at that thing and think Book (not Wiki). Book as in, let me try to be pedagogical. Not Wiki as in, let me slap down what I know any old way.

There ya go. Three paragraphs of rambling nonsense with Capital Letters liberally sprinkled throughout. I'd better go home and try to do something useful with my time instead.

ssh does indeed invoke a shell

windows, ssh stuff, dates and the mystery bug

Stayed home from work yesterday, giving myself the excuse that I was sick. Probably should have gone to work instead, because it turns out I was feeling ok enough to do a bit of darcs-hacking. Also played hooky a bit this morning (it's 11:06), but overall, I'm glad to have spent time getting this stuff out of the way... clears my head, let's me focus on other things.

windows and weird filenames

A user on IRC was trying to work around issue53 where Windows enforces a bunch of naming conventions like "don't start your filenames with AUX". I don't think I personally am going to do something about this, but my proposal is that, when we are running on Windows, we should treat patches that affect such files as affecting some other file instead, one with a translated name. So if we have a patch that affects AUX.dtd, we should apply the changes to -AUX.dtd or something; and print out a warning saying what we have done and why. This solution at least allows the patches to apply, but it does have some problems of its own, like (1) what if a file with the translated name already exists? (2) what if the user tries to modify the translated file? Do we want to recognise that? [I'd say, we probably should, but rather than let the user record changes, we just say "Whoops! you don't want to touch this file. Please mv it to something safe instead."] Mmmhh. I dunno if this is going to work, or if it's just going to make things super-complicated and introduce a bunch of random bloat. Well, in any case, we should at least detect the problem and tell the user about it. I suppose simply ignoring such files (and printing a warning) is just as good, and much simpler to boot. (If we were to ignore them, we should at least try to handle the mv, though, although that too is complicated)

get --to-match

Whilst trying out the IRC-user's problem on the darcs repository, I ran into this.

% darcs get --to-match='exact "More fixes to unrecord."' ~/darcsImpl/stable
Copying patch 3831 of 3831... done!
darcs: failed to read patch in get_extra:
Sun May 22 13:40:59 GMT 2005  David Roundy 
  * extend revert_interactive test to do a trickier revert.
Perhaps this is a 'partial' repository?

Ouch! I should check the bug tracker and see if we have anything like it.

plink, Windows, ssh stuff

We had decided to reject my new ControlMaster patch because it was fragile, and then we weren't sure about the other patches which were essentially supposed to make Windows shut up when doing ssh stuff (so we don't get spurious plink -O error messages). I finally had a chance to sit down and review these patches. It seems that it is ok for us to apply them independently of the control master stuff. I have resubmitted the patches and made a request for review. Well, all patch submissions are implicitly a request for review, but I wanted to particularly call attention to this bit.

dates and the mystery bug

I had a filed a bug report for a mysterious issue involving the darcs repository inventory. Juliusz looked into it and found that it was due to a cleanDate patch. The basic problem is that PatchInfo.make_filename uses cleanDate to parse the date info in old-school patches. Old school patches write their dates in human-readable format, which is rather useless because it's just an internal representation and harder to parse.

Case in point, the mystery bug. I had submitted a patch to fix issue173 (timezones not recognised correctly)... what the patch does is to correct cleanDate so that dates are converted to UTC before being printed out. I think this is the correct behaviour, because otherwise, timezones are just truncated; which would be very bad because somebody reading the time string in would have little choice but to assume UTC.

So I think my patch is correct: but it breaks old patches, because the patch in question was dated Sun Sep 21 11:57:26 EDT 2003, which is intepreted

 before: 2003-09-21 11:57 (wrong!)
 after:  2003-09-21 15:57 (EDT is UTC-4, so add 4 back)

Unfortunately, the filename generated was using the incorrect time (2003-09-21 11:57). Ick. So what I proposed is that we continue supporting this broken behaviour (it doesn't really matter anyway, it's just what filename we give to it), by using showIsoDateTime.readDate and a small comment saying that this is wrong, but we don't really care.

Anyway, I hope I haven't simply confused myself. I think this analysis of things is correct, maybe the next action is wrong, but I'm pretty sure that's where things went wrong. Sometimes seems that it's impossible to program a computer without being super anal about everything.

patch bundles

I have one particularly bad habit when submitting patches, and that is grouping my patches into thematic bundles, rather than dependency bundles. Why is this bad? It causes confusion! It makes people think that certain patches go together, when in fact the only thing about them is that they are related to common themes, like "date parsing". I need to get a better eye for grouping my patches so that things work out smoother for everybody.

Stayed home from work yesterday, giving myself the excuse that I was sick. Probably should have gone to work instead, because it turns out I was feeling ok enough to do a bit of darcs-hacking. Also played hooky a bit this morning (it's 11:06), but overall, I'm glad to have spent time getting this stuff out of the way... clears my head, let's me focus on other things.

windows and weird filenames

A user on IRC was trying to work around issue53 where Windows enforces a bunch of naming conventions like "don't start your filenames with AUX". I don't think I personally am going to do something about this, but my proposal is that, when we are running on Windows, we should treat patches that affect such files as affecting some other file instead, one with a translated name. So if we have a patch that affects AUX.dtd, we should apply the changes to -AUX.dtd or something; and print out a warning saying what we have done and why. This solution at least allows the patches to apply, but it does have some problems of its own, like (1) what if a file with the translated name already exists? (2) what if the user tries to modify the translated file? Do we want to recognise that? [I'd say, we probably should, but rather than let the user record changes, we just say "Whoops! you don't want to touch this file. Please mv it to something safe instead."] Mmmhh. I dunno if this is going to work, or if it's just going to make things super-complicated and introduce a bunch of random bloat. Well, in any case, we should at least detect the problem and tell the user about it. I suppose simply ignoring such files (and printing a warning) is just as good, and much simpler to boot. (If we were to ignore them, we should at least try to handle the mv, though, although that too is complicated)

get --to-match

Whilst trying out the IRC-user's problem on the darcs repository, I ran into this.

% darcs get --to-match='exact "More fixes to unrecord."' ~/darcsImpl/stable
Copying patch 3831 of 3831... done!
darcs: failed to read patch in get_extra:
Sun May 22 13:40:59 GMT 2005  David Roundy 
  * extend revert_interactive test to do a trickier revert.
Perhaps this is a 'partial' repository?

Ouch! I should check the bug tracker and see if we have anything like it.

plink, Windows, ssh stuff

We had decided to reject my new ControlMaster patch because it was fragile, and then we weren't sure about the other patches which were essentially supposed to make Windows shut up when doing ssh stuff (so we don't get spurious plink -O error messages). I finally had a chance to sit down and review these patches. It seems that it is ok for us to apply them independently of the control master stuff. I have resubmitted the patches and made a request for review. Well, all patch submissions are implicitly a request for review, but I wanted to particularly call attention to this bit.

dates and the mystery bug

I had a filed a bug report for a mysterious issue involving the darcs repository inventory. Juliusz looked into it and found that it was due to a cleanDate patch. The basic problem is that PatchInfo.make_filename uses cleanDate to parse the date info in old-school patches. Old school patches write their dates in human-readable format, which is rather useless because it's just an internal representation and harder to parse.

Case in point, the mystery bug. I had submitted a patch to fix issue173 (timezones not recognised correctly)... what the patch does is to correct cleanDate so that dates are converted to UTC before being printed out. I think this is the correct behaviour, because otherwise, timezones are just truncated; which would be very bad because somebody reading the time string in would have little choice but to assume UTC.

So I think my patch is correct: but it breaks old patches, because the patch in question was dated Sun Sep 21 11:57:26 EDT 2003, which is intepreted

 before: 2003-09-21 11:57 (wrong!)
 after:  2003-09-21 15:57 (EDT is UTC-4, so add 4 back)

Unfortunately, the filename generated was using the incorrect time (2003-09-21 11:57). Ick. So what I proposed is that we continue supporting this broken behaviour (it doesn't really matter anyway, it's just what filename we give to it), by using showIsoDateTime.readDate and a small comment saying that this is wrong, but we don't really care.

Anyway, I hope I haven't simply confused myself. I think this analysis of things is correct, maybe the next action is wrong, but I'm pretty sure that's where things went wrong. Sometimes seems that it's impossible to program a computer without being super anal about everything.

patch bundles

I have one particularly bad habit when submitting patches, and that is grouping my patches into thematic bundles, rather than dependency bundles. Why is this bad? It causes confusion! It makes people think that certain patches go together, when in fact the only thing about them is that they are related to common themes, like "date parsing". I need to get a better eye for grouping my patches so that things work out smoother for everybody.

windows, ssh stuff, dates and the mystery bug

tailor needs a recent CVS

Having trouble bootstrapping from CVS (say, via anonymous pserver on sourceforge)? Try upgrading. It wasn't working for me with cvs 1.10, but 1.11 did the trick.

Having trouble bootstrapping from CVS (say, via anonymous pserver on sourceforge)? Try upgrading. It wasn't working for me with cvs 1.10, but 1.11 did the trick.

tailor needs a recent CVS