[01:48] <cr3> how can I recover an old file which has been bzr removed from the repository at some point?
[02:00] <cr3> nevermind, found it with diff -r
[03:18] <lnxtech> Has anyone gotten bzr-gtk to run on OS X Leopard?  I'm trying with both the built in python and also from macports but I haven't gotten it to work yet
[03:36] <sabdfl> lifeless: hi
[04:48] <lifeless> sabdfl: hola
[05:42] <sabdfl> hey lifeless
[05:42] <sabdfl> thanks for the answers
[18:22] <lifeless> morning y'akk
[18:43] <abentley> jelmer: ping
[18:47] <juh> Hi, I cannot push anything to the repos on my server
[18:47] <juh> using bzr locally works
[18:48] <juh> is there a tutorial who to set up bzr on a server?
[18:49] <lifeless> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
[18:53] <lifeless> you don't need bzr on the server if you are using sftp or ftp
[18:54] <lifeless> if you are using bzr:// e.g. bzr+ssh:// then you need a bzr on the server, we try to be network compatible release to release.
[18:55] <juh> lifeless: thanks I think that it works now somehow
[20:07] <woei> I'm having some problems with the bzr-gtk (0.92.1) on a netbsd-4 (python2.4) machine. Python dumps core because it gets sent SIGSEGV: http://pastebin.com/d48960808
[20:08] <woei> base bzr runs flawlessly however
[20:23] <lifeless> woei: interesting; I would guess its a python-gtk bug
[20:32] <woei> lifeless: ok, I'll try updating pygtk to 2.12 (it's at 2.10.6 now)
[22:42] <pattern> i'm about to write a little script to get version information from bazaar in the form that perl modules expect (ie. versions of the form "X.Y.Z", where "X", "Y", and "Z" are all integers), and would like some input from anyone with more experience with bazaar on whether i'm going about this the right way...
[22:44] <pattern> bazaar seems to number its revisions with a single number... which is fine... my idea is to just tag a revision i'm about to release with something like "myproject-X.Y.Z"
[22:44] <pattern> unfortunately "bzr version-info" does not specify which tag a version has
[22:45] <pattern> so i'm thinking of grabbing "revno" from "bzr version-info" and then searching for it in the output of "bzr log"
[22:46] <pattern> if it finds a tag matching the regex: "\w-\d\.\d\.\d" (ie. "word-digit.digit.digit") it'll use the "digit.digit.digit" part for the version number
[22:47] <pattern> otherwise it'll keep looking down the list of revisions until it finds such a tag and use that
[22:47] <pattern> i know this is kind of ugly and hackish, but i don't know what else to do
[22:52] <lifeless> bzr revision-info will give you the unique revision id of your tree
[22:52] <pattern> isn't that the same as the "revno:" line in "bzr version-info" ?
[22:53] <lifeless> no, its a guid
[22:53] <lifeless> 'bzr tags' will list the tags you have
[22:53] <pattern> yes, but that doesn't tell me which tag the currently checked out working tree has
[22:54] <pattern> i suppose i could just use the top-listed tag
[22:54] <pattern> and assume i'm working with the newest revision
[22:54] <pattern> but that might not always be the case
[22:56] <lifeless> uhm
[22:56] <igc> morning
[22:56] <lifeless> I thought tags listed the tag
[22:56] <lifeless> revno/revisionid
[22:57] <lifeless> hi igc
[22:57] <igc> hi lifeless
[22:58] <pattern> as i understand it, "bzr tags" lists all the tags for the branch
[22:58] <pattern> but i'm interested in just the tag for the revision of the branch that i have checked out
[22:59] <pattern> so i think i'm going to have to search through the output of "bzr log" for that
[22:59] <lifeless> pattern: there may be no such tag
[22:59] <pattern> yes
[22:59] <pattern> in which case i guess i'll have to use the newest tag for any older revision
[23:00] <pattern> as i need to set my $VERSION to something
[23:00] <lifeless> and I'm saying that looking for bzr revision-info in the output of bzr tags is the fast way to do that if you don't want to use python
[23:00] <lifeless> pattern: but if you just want to specify 'the current tree', the guid from bzr revision-info is all you need
[23:00] <lifeless> perhaps I'm not understanding what you are trying to do
[23:01] <pattern> well, "bzr revision-info" just gives me a single digit... i need to get a version in the form of "X.Y.Z" (where each of "X", "Y", and "Z" are digits)
[23:01] <lifeless> pattern: I don't know why you need that, and revision-info doesn't give a digit, it gives a revno and revid; the revid is the unique part
[23:02] <lifeless> e.g.
[23:02] <lifeless> bzr revision-info
[23:02] <pattern> so i think the way to get that is to manually set a tag for the version i want (ie. "myproject-1.0.2")
[23:02] <lifeless> 2939 pqm@pqm.ubuntu.com-20071024231045-lquhgsz9513gn2l4
[23:02] <pattern> the reason i need that is because perl modules are usually numbered in that way
[23:02] <lifeless> the 'pqm@pqm.ubuntu.com-20071024231045-lquhgsz9513gn2l4' is the right thing to use to refer to this commit in a guaranteed manner
[23:03] <lifeless> pattern: perhaps if you start from the top; I'm really confused
[23:03] <pattern> ok...
[23:03] <pattern> i'm writing a perl module... perl modules usually have a $VERSION (version string)
[23:03] <pattern> $VERSION is used internally by the standard makefiles that compile and package up the module, and for module naming
[23:04] <pattern> and they're usually in the form "X.Y.Z" (where each of "X", "Y", and "Z" are digits)
[23:04] <pattern> usually that $VERSION lives in the code itself
[23:05] <lifeless> ok
[23:05] <pattern> but i don't want to mess with the code manually.. because i might make a mistake and get $VERSION out of sync with the actual revision in bazaar
[23:05] <lifeless> so why not just append .0.0 to what bzr supplies ?
[23:06] <pattern> well, releasing new major numbers (the first digit) is usually frowned upon unless you've made massive changes (ie. that require a reconfig, and/or API/format-changes, etc)
[23:06] <lifeless> or do
[23:07] <lifeless> 0.bzrrevno.0 ?
[23:07] <lifeless> or 1.0.bzrrevno ?
[23:07] <pattern> and then how do i increment the first and last digits?
[23:07] <pattern> or whatever digits bzrrevno doesn't account for?
[23:07] <pattern> it just makes much more sense to tag the release manually
[23:07] <lifeless> well, increment them whenever you want to
[23:07] <pattern> but have it in sync with the revision in bazaar
[23:08] <pattern> so i can check out the branch based on that tag
[23:08] <lifeless> but if you do want to use bzr tags, sure, using log and looking back for a tag will work, though you will get the same VERSION for different commits until you tag a new version
[23:08] <pattern> yeah, that is a problem
[23:09] <pattern> i'm going to have to give it more thought
[23:10] <pattern> or maybe i could just tag every revision
[23:10] <pattern> as X.Y.bzrrevno
[23:11] <pattern> and when i do releases just use X.Y.0
[23:11] <lifeless> which is the same as not tagging
[23:12] <lifeless> and using x.y.bzrrevno all the time except for releases
[23:13] <pattern> well, then if there's no tag on a version i'd need to search through earlier log entries for tags to know what X.Y is
[23:13] <lifeless> ssure
[23:13] <pattern> why not just tag every revision?
[23:13] <pattern> i could probably write a script to do it, using the previous value of X.Y, and allowing an override
[23:13] <lifeless> seems redundant and needs more work
[23:13] <lifeless> I'd just tag once, and look that up
[23:14] <pattern> it's too bad "bzr version-info" doesn't tell me the tag of the current revision
[23:14] <pattern> then i wouldn't need to search "bzr log" for it
[23:15] <lifeless> but as discussed there may be no tag
[23:15] <lifeless> unless you've tagged every time
[23:15] <pattern> right
[23:15] <pattern> which is what i think i'm going to do
[23:15] <lifeless> certainly, please do file a bug about it not providing the tag
[23:16] <pattern> well, then maybe there should be a "bzr tag-info" :)
[23:16] <i386> lifeless: http://confluence.ts.wikimedia.org/display/main/Home
[23:16] <pattern> though, i think that while "bzr version-info" is providing all sorts of other info on that revision (such as the date and branch), it might as well provide the tag as well
[23:17] <lifeless> pattern: sure; file a bug :)
[23:17] <pattern> will do :)
[23:20] <lifeless> i386: :)
[23:20] <i386> lifeless: :)
[23:25] <pattern> actually, "bzr log -r `bzr revno`" will accomplish pretty much the same as what having "bzr version-info" report the tag would do
[23:26] <pattern> and "bzr log -r `bzr revno` | grep tag" to get the tag itself
[23:27] <pattern> it's still a bit hackish... but seems to work
[23:28] <lifeless> you can use 'bzr log -r -1'
[23:29] <pattern> ah
[23:29] <pattern> nice :)
[23:29] <pattern> "bzr log -r -1 | grep tags | sed 's/^tags: //'"
[23:33] <pattern> now to write a little script that does that before running a commit, and then automatically tagging the newly committed revision with X.Y.revno (where X.Y comes from the previous tag, and revno is the current revision)
[23:33] <pattern> and when i want to increment X.Y i'd do so manually instead of running that script
[23:34] <pattern> or maybe give the script an override option
[23:34] <lifeless> its this complexity I don't like about tagging every commit
[23:34] <lifeless> you wouldn't have to wrap commit if you only tagged releases
[23:35] <pattern> well, it's either that or having to search through multiple log entries for the last tagged revision before the revision i'm working on now
[23:36] <pattern> both ways entail additional complexity
[23:36] <pattern> at least if i tag every revision, then i'd instantly know the X.Y version number of every revision by simply looking at the log for that revision
[23:38] <lifeless> so one is prone to failing if you forget to use your wrapper
[23:38] <lifeless> the other isn't prone to failing at all
[23:38] <lifeless> shrug, its up to you :)
[23:39] <pattern> there's no "bzr alias", eh?  :)
[23:39] <lifeless> you can alias commit to give you options and so on, but not to run a shell script - your shell's alias can do that
[23:40] <pattern> but shell aliases only alias the first word on the command line
[23:40] <lifeless> a precommit hook could do what you need too, though noone has actually wired up the glue for precommit hooks just yet - we've been waiting for a use ase
[23:40] <pattern> so i'd need to create a "bzrcommit" alias
[23:40] <pattern> which, as you point out, i might forget to type
[23:42] <pattern> but, if i do forget to type "bzrcommit" and type "bzr commit" instead, the next time i type "bzrcommit" or the next time i run make my "bzrcommit" script or the scripts in the makefile could warn me about not seeing a tag for the current revision
[23:42] <pattern> and i could also have a script that goes back and adds any missing tags
[23:42] <pattern> that would be trivial
[23:43] <pattern> of course, doing that would involve searching through the output of "bzr log"
[23:43] <pattern> so maybe instead of creating a wrapper for "bzr commit" i should create a wrapper for "bzr log" instead
[23:46] <pattern> well, one other advantage of tagging every revision is that i could always check out a given revision via its tag, which would include the X.Y version number... and that would make more sense than just using the revno alone
[23:49] <lifeless> I worry that you will run into scaling problems with tags
[23:50] <lifeless> they're not geared for thousands of them
[23:50] <pattern> hmm
[23:50] <lifeless> and you're really just duplicating our existing infrastructure
[23:50] <lifeless> which is why x.y.REVNO is IMO superior, for non-releases
[23:50] <lifeless> you can 'bzr branch -r REVNO' as well
[23:51] <pattern> or "bzr branch -r tag:X.Y.REVNO", right?  :)
[23:51] <lifeless> yes, but thats redundant
[23:51] <lifeless> so there is no gain; thats my point
[23:52] <pattern> the gain is in a more intuitive user experience when looking for a given X.Y.REVNO version
[23:52] <lifeless> still; if you feel you need to, it will work, it will just incrementally slow down your push/pull operations
[23:53] <lifeless> couldn't you just add a VERSION_ID to the perl script
[23:53] <lifeless> which is the GUID ?
[23:53] <pattern> well, it needs to be in the X.Y.Z format, which is the standard
[23:53] <lifeless> thats even easier in terms of getting the code for that version, and more robust against things like uncommit
[23:53] <lifeless> no, you miss my poin
[23:53] <lifeless> use VERSION for the build stuff
[23:53] <lifeless> use VERSION_ID for the bzr GUID, as ancilliary data
[23:54] <pattern> i don't understand
[23:54] <lifeless> you seem to have several use cases
[23:54] <pattern> could you explain what VERSION_ID and GUID are?
[23:54] <lifeless> case 1) provide a machine generated version number for each build; which will be semi-human-readable
[23:54] <lifeless> case 2) provide a way for users to obtain the source code
[23:55] <lifeless> VERSION_ID would just be a perl variable
[23:55] <pattern> and that would be different from VERSION ?
[23:55] <lifeless> the GUID is what is returned by 'bzr revision-info', e.g. pqm@pqm.ubuntu.com-20071024231045-lquhgsz9513gn2l4
[23:56] <pattern> how is using GUID better than the output of "bzr revno" ?
[23:56] <lifeless> it does the correct thing when people uncommit
[23:56] <pattern> and, more importantly, how do i get a proper X.Y.Z formatted version number for the perl VERSION variable?
[23:56] <lifeless> it works in any branch of the project regardless of merge history
[23:56] <pattern> ah
[23:57] <lifeless> the guid is the underlying database id
[23:57] <pattern> well, that makes things more complicated
[23:57] <lifeless> for the Z component, I'd use the bzr revno, as you don't plan on uncommitting in your mainline, or even just lookup your last actual build you released, or use a timestamp (e.g. Z is seconds-since-epoch)
[23:58] <pattern> maybe i could just append an md5sum of GUID :)
[23:58] <lifeless> md5's have a-f in them
[23:58] <pattern> yeah, i was joking
[23:58] <lifeless> if thats permitted, just using the guid directly :).
[23:59] <pattern> i think perl users would flip if they saw a 30 digit number in their version string
[23:59] <pattern> and it's not permitted
[23:59] <pattern> i don't think