[00:54] <poolie> spiv, i'm alive :)
[00:56] <spiv> Oh good :)
[07:17] <poolie> hi spiv
[07:17] <poolie> the changelog thing was ok
[07:17] <poolie> thanks for adding it to whatsnew
[07:20] <vila> hi all !
[07:21] <vila> spiv: there a re uncommitted changes on jubany regarding delete_branches (sp?), can you have a look ?
[07:25]  * jelmer waves
[07:30] <poolie> hi vila
[07:31] <vila> poolie: hey !
[07:34] <jelmer> what are we going to use for the standup, skype/mumble/... ?
[07:40] <spiv> vila: oh right
[07:40] <spiv> vila: I think probably they should just be committed; I was thinking maybe I'd try polish them a little but I don't think it's worth spending more time on that.
[07:41] <vila> spiv: by the way, do you when bzr was upgrade to 2.3b5 on jubany ?
[07:41] <spiv> vila: it's changes necessary to make it work with the launchpadlib version and maybe other aspects of jubany
[07:41] <spiv> vila: Not sure, but I can probably infer from the bug or RT, let me see if I can dig that up
[07:47] <spiv> vila: https://bugs.launchpad.net/udd/+bug/653307/comments/25 implies the upgrade happened between 2011-02-02 and 2011-02-04
[07:51] <vila> spiv: ha! right, thanks, I read that but the bit about upgrading didn't stick in my mind.
[07:52] <spiv> vila: no problem
[07:54] <vila> spiv: on a related note, http://package-import.ubuntu.com/status/gobject-introspection.html#2011-03-15%2015:06:47.074448 is quite obscure and may be related to the fetch changes ?
[07:54] <vila> s/obscure/obscure to me/
[07:55] <spiv> vila: that's a fixed bug, waiting on an RT for a bzr upgrade :(
[07:55] <spiv> vila: https://bugs.launchpad.net/udd/+bug/726584 I think
[07:56] <vila> haaaa, *another* bzr upgrade ! ... /me connects the dots
[07:56] <vila> pfew, thanks spiv
[07:56] <spiv> vila: presumably taking a while due to a recent LOSA shortage
[07:57] <vila> spiv: but also requires 2.3.1 which is not in ppas yet !
[07:57] <vila> maxb: any news about 2.3.1 in ppas ?
[07:57] <spiv> vila: I don't think that's a blocker
[07:58] <vila> spiv: that == ?
[07:58] <spiv> vila: (that == no PPA build yet) check the version of the package on jubany
[07:58] <jelmer> spiv: g'day!
[07:58] <jelmer> spiv: your mumble works :)
[07:58] <spiv> jelmer: :)
[07:59] <jelmer> spiv: mine just freezes and doesn't let me unmute..
[07:59] <jelmer> (yet audio works...)
[08:00]  * spiv logs off the evening
[08:03] <poolie> oh, no :)
[08:03] <poolie> time flies
[08:03] <poolie> did you gues stand up without me?
[08:03] <jelmer> spiv and I said hi on mumble, which was nice :)
[08:03] <jelmer> I'm not sure if that counts as a standup
[08:04] <poolie> is jam here?
[08:04] <jelmer> haven't seen him yet, here or on mumble
[08:07] <poolie> ok i think i'm on
[08:13] <jam> hi po
[08:13] <jam> hi poolie
[08:13] <jam> yeah, I didn't get back in time
[08:15] <poolie> i was concentrating and missed it
[08:15] <poolie> you can join us now
[08:16] <mr-russ> question about reviews and mergre proposal for bzr on launchpad.
[08:17] <poolie> sure
[08:17] <mr-russ> If my code is reviewed, and set to Needs Information, how does it go back to needs review?
[08:17] <mr-russ> Does pushing further commits do that?
[08:17] <mr-russ> https://code.launchpad.net/~mr-russ/bzr/add-doc-for-shared-ssh-server/+merge/53217
[08:18] <mr-russ> specifically this is my first lp bzr merge and I really don't know how it all fits together.
[08:18] <poolie> no, you'll need to set it back to 'needs review' through the web ui when you're happy with the state
[08:18] <poolie> or click 'resubmit'
[08:19] <mr-russ> status is need review, so that's correct?
[08:19] <jelmer_> poolie: I can't really hear you, getting a lot of echo
[08:19] <poolie> vila, can you mute yourself (click the microphone icon)
[08:21] <vila> poolie, jelemer: I begin to hear you and have my micro off (which I suspect was the reason you muted me ?)
[08:29] <poolie> vila, yes, if you have a desktop mic and speakers i think you'll need to mute yourself when not talking
[08:29] <poolie> the echo suppression is not all that smart
[08:29] <vila> poolie: yeah, I'm pretty much in this mode now mute/unmute is a click away, I think I'll stick with that for now
[08:52] <vila> looks like I lost my micro :-/
[08:53] <poolie> wow i like the Darth Vader effect :)
[08:54] <fullermd> You should get a macro instead.  They're easier to find.
[09:12] <jelmer_> vila, jam, poolie: https://wiki.ubuntu.com/JelmerVernooij/PerPackageUploaderApplication
[09:14] <vila> poolie, jam, jelmer: I just learned the 'jackhammer' word, that's what they are using under my windows, so, sorry for the bad audio today :-/
[09:14] <poolie> haha seriously?
[09:14] <poolie> not angry ghosts?
[09:14] <jam> vila: it went ok. Though you should configure push-to-talk rather than push to unmute. The ding when you started talking was a bit annoying.
[09:14]  * jelmer_ looks up jackhammer..
[09:14] <vila> hehe,yeah seriously :-/
[09:14] <jam> http://en.wikipedia.org/wiki/Jackhammer
[09:15] <jam> that ding
[09:15] <jelmer_> ha, thanks jam
[09:17] <poolie> what is it in fr/nl?
[09:18] <soren> Wikipedia tells you, too. Lower left corner has links to other languages.
[09:18] <soren> Drilboor in nl, Marteau-piqueur in fr :)
[09:19] <mr-russ> what conference tool are you using?
[09:20] <vila> mumble, quite amazing audio quality even compared to POTS from europe to australia
[09:21] <vila> soren: hehe, yeah, I went the opposite route to get the english word :)
[09:21] <soren> vila: Wikipedia is a surpringsly good translation tool that way. :)
[09:22] <vila> soren: yeah, at least you can ensure that you use the right word
[09:22] <mr-russ> Poolie in AU?
[09:23] <poolie> quite amazing audio quality _when you consider one participants has jackhammers in the background_ :)
[09:23] <poolie> yes
[09:24] <mr-russ> poolie: where in AU, I'm in northern Melbourne.
[09:25] <vila> mr-russ: sydney
[09:25] <vila> LOL
[09:26] <vila> mumble shorcuts are *global* so I should definitely *not* use 'm' as a shortcut :)
[09:26] <mr-russ> that would be bad.
[09:26] <poolie> desktop-wide?
[09:26] <jelmer_> vila: Ah, I remember what the issue with the 2.3.1 upload was. The python-configobj triple quotes patch hasn't made it into the python-configobj package yet
[09:26] <vila> are always use type m twice :)
[09:26] <jelmer_> vila: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618349
[09:26] <vila> jelmer: ooooh, bad bad bad
[09:27] <jelmer_> I've forwarded the patch to the packager a couple of days ago, will ping and nmu
[09:27] <jelmer_> Odd_Bloke: hi :)
[09:29] <maxb> vila: whoops. I can do 2.3.1 in ~bzr tonight
[09:30] <vila> maxb: that would be awesome !
[09:30] <poolie> hi maxb, odd_bloke
[09:30] <poolie> and good night
[09:31] <jelmer_> g'morning maxb
[09:31] <jelmer_> have a good evening poolie
[09:31] <vila> poolie: g'night poolie
[09:32] <maxb> morning indeed
[09:32]  * maxb should go to work :-)
[09:46] <vila> jelmer: argh, no 'Nominate for series' for me on bug #707075, ISTR encountering the issue last time but not the workaround...
[09:47] <vila> using https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075 doesn't help
[09:50] <vila> jam or james_w : care to review https://code.launchpad.net/~vila/udd/608563-requeue-all-of-type/+merge/53527 ?
[09:54] <Odd_Bloke> jelmer_: o/
[10:01] <jelmer_> Odd_Bloke: hi! How's things?
[10:06] <jelmer_> jam: I reviewed some of the easier loggerhead branches, looking at page_loading now..
[10:11] <Odd_Bloke> jelmer_: Not bad, thanks.
[10:11] <Odd_Bloke> Busy couple of weeks at work, as we're delivering training every Friday.
[10:11] <Odd_Bloke> Yourself?
[10:12] <jelmer_> Odd_Bloke: Pretty good - enjoying hacking on bzr fulltime.
[10:12] <Odd_Bloke> :)
[10:14] <jelmer_> Odd_Bloke: I filed a report against python-configobj about a bug that's blocking a bzr upload to sid. I was wondering if there was any chance of an upload or if it was perhaps ok if I did one?
[10:14] <Odd_Bloke> jelmer_: You're welcome to do so.
[10:14] <Odd_Bloke> I'm going to be writing training material for what feels like the rest of my life, so won't have time. :p
[10:14] <jelmer_> heh
[10:15] <jelmer_> Odd_Bloke: what's the training on?
[10:25] <Odd_Bloke> jelmer_: FreePBX, an Asterisk front-end.
[10:26] <jelmer_> ah
[10:34] <vila> and now we are *too* fast ? wth ? http://babune.ladeuil.net:24842/job/selftest-hardy/430/testReport/junit/bzrlib.tests.test_selftest/TestTestResult/test_test_reporting/
[10:42] <jelmer_> vila: is there a package associated with the 2.2.4 SRU?
[10:42] <vila> jelmer: I don't think so nor do I know how to build one
[10:43] <spiv> vila: -2ms, nice.  System clock got updated during the test run?
[10:43] <vila> spiv: vbox....
[10:43] <vila> spiv: but yeah, probably some weird thing like that...
[10:51] <fullermd> Surely such a thing couldn't happen with vbox's punctilious attention to precision timekeeping...
[11:03] <jelmer_> vila: okay, I'll prepare one
[11:05]  * vila afk trying to address a violent headache :-(
[11:06] <vila> at least the jackhammers have stopped (but that's probably their lunch brea k:-/)
[11:21] <jelmer_> vila: done
[11:36] <jam> mgz: poke about test_tar_export
[11:36] <jam> did you get anywhere?
[11:37] <mgz> I had to stop shortly after posting the patch-thus-far, I was trying to get plain_tar_export to fail, but it was not doing what I expected
[11:37] <mgz> and I need to leave in ~5mins, but will be around later
[11:37] <mgz> *plain_tar_exporter
[11:38] <mgz> it also opens a file in non-binary mode before passing it to tarfile.open, and doesn't seem to have a seperate test in test_export currently
[11:40] <jam> mgz: do you have it somewhere for me to start from?
[11:41] <jam> jelmer_: update to configurable_logging: lp:~jameinel/loggerhead/configurable_logging
[11:41] <jam> I updatet setup_logging so it can be reused by both places
[11:41] <jam> care to look at it?
[11:41] <jam> or shall I just land?
[11:43] <mgz> nothing committed on the branch, still at experiment-and-poke stage
[11:43] <mgz> http://paste.ubuntu.com/581048/ <- diff of tree
[11:43] <mgz> something's wrong with that test I was trying to add, was too tired to work out what I'd messed up.
[11:45] <mgz> your idea to change those open functions sounded good, also adding 'b' to tarfile.open and GzipFile in the same file would be clearer even though those functions will fix up the flags for you.
[11:47] <jelmer_> jam: I guess the init_logging bit could also be inline in loggerhead.main as it's just two lines and specific to the standalone loggerhead
[11:47] <jelmer_> jam: either way, +1
[11:47] <mgz> (relying on your random data trick and not asserting the compressed contents contain a \n is probably right, worst case is a spurious pass and it'll catch regressions)
[11:48]  * mgz is off
[11:48] <jam> mgz: catch ya later
[11:56] <jelmer_> vila: hmm, perhaps we should do the UDD thing and propose the SRU using a MP
[12:36] <maxb> jelmer: I'd be tempted to eschew UDD for bzr, given we already have nice packaging branches which the importer unnecessarily reimports - my 2.2.2 sru attempt was derived from the bzr.debian.org branch
[12:38] <jelmer_> maxb: There isn't much benefit in using the packaging branches though, especially for something like a SRU
[13:34] <vila> jelmer_: thanks. Looking at the branch, am I right guessing that your merged lp:bzr/2.2 and then add the debian/changelog entry (most of the work there) and commit ? Or did you need more work ?
[13:36] <jelmer_> vila: no, that's it. I also fixed the watch file. So if you have a newer bzr builddeb it's a matter of:
[13:36] <jelmer_> bzr branch lp:ubuntu/maverick-proposed/bzr sru && cd sru && bzr merge-upstream && dch && debcommit -r && bzr push
[13:38] <jelmer_> s/bzr push/bzr push lp:~jelmer/ubuntu/maverick/sru-2.2.4
[13:39] <vila> yup, got that ;) Trying to reproduce locally
[13:41] <vila> hmm, Using version string 2.3.1. doesn't look good ;)
[13:42] <jelmer_> vila: hmm?
[13:43] <vila> looks like I need to use ' bzr merge-upstream --version 2.2.4'
[13:44] <jelmer_> vila: when merging 2.2.4 ?
[13:44] <jelmer_> vila: ah, the issue is probably that you hadn't updated debian/watch
[13:44] <jelmer_> vila: so it would use the latest version
[13:44] <jelmer_> vila: that bit is fixed in my branch
[13:44] <jelmer_> r-2
[13:44] <vila> hmm, ok, so I should do that *before* merge-upstream, trying
[13:45] <vila> oic
[13:48] <vila> indeed, better
[13:49] <vila> only difference is now the bzrlib/tests/per_tree/test_is_executable.py file which has a different file-id :-/
[13:57] <vila> jelmer_: hehe, tried the same trick for 2.1 which failed because the https://launchpad.net/bzr/+download doesn't contain the 2.1 series :)
[13:58] <jelmer_> vila: we should probably the link in debian/watch to point at 2.1 series page
[13:58] <vila> yup, looking into it
[14:01] <vila> hmm, there is no such thing as a 2.1 download page it seems...
[14:04] <jkakar> Hi!  Is there a way to edit old commit messages in a Bazaar branch?
[14:04] <jkakar> I have a trunk branch that uses a specific commit message format... a few revisions don't use the format, and I'd like to clean them up, if it's reasonably easy to do so.
[14:04] <soren> jkakar: It's not.
[14:46] <jam> jkakar: it isn't particularly hard to do recent commits, but really old ones is a problem
[14:51] <vila> jam, jelmer: care to join mumble to test my new setup ?
[14:55] <jam> vila: do I dare? :)
[14:55] <vila> jam: yeah, should far better, the jackhammers are gone too ;)
[14:56] <jam> I don't hear you saying anything
[14:56] <jam> but I see the lips go red for you
[14:56] <jam> vila: do you hear me?
[14:56] <vila> jam: I hear you
[14:58] <vila> wow, weird, mumble gives feedback as if it hear something but you don't :-/
[15:34] <fullermd> Maybe it just doesn't like what it hears, and refuses to repeat it   :p
[15:38] <vila> :)
[15:39] <vila> jelmer_: bug #646961 has been fixed ub 2.3b4, since natty already ships 2.3.0, I can mark it FixReleased for bzr(Ubuntu) right ?
[15:40] <vila> jelmer_: or does that need to go through the packaged debian/changelog or are both correct ?
[15:41] <CaMason> hello. I have a commit (a few commits back) that I need to remove (more specifically, undo)
[15:42] <CaMason> what's the proper way to do this? I know which revision(s) need to go
[15:52] <jelmer_> vila: sorry, must've missed a notification while I was getting coffee
[15:52] <jelmer_> vila: yes, please close it as FixReleased if the version that fixes it has already been uploaded
[15:52] <vila> ok
[16:08] <vila> jelmer_: can you have a look at lp:~vila/ubuntu/lucid/bzr/sru-2.1.3 and tell what you think ?
[16:09] <vila> jelmer_: (2.1.4 is planned for 2011-03-24 so this is only a warm-up ;)
[16:11] <vila> jelmer_: and the debian/watch trick is horrible but I've filed bug #736145
[16:14] <vila> hmm, I just made him fall from his chair unplugging his laptop...
[16:16] <kazade> Quick question, how do I tell if there are more recent revisions on a remote branch without just pulling them in?
[16:17] <CaMason> how can I get bazaar to output a patch with binary data includeD?
[16:17] <beuno> kazade, bzr missing REMOTE_BRANCH
[16:18] <kazade> thanks beuno
[16:19] <kazade> hmm, does that work the other way too? (e.g. if you have a commit that remote doesn't)
[16:25] <vila> kazade: yes
[16:26] <vila> CaMason: bzr send
[16:26] <beuno> kazade, there's a flag
[16:26] <beuno> --just-mine or soemthing, see "bzr help missing"
[16:26] <kazade> --mine-only
[16:26] <kazade> thanks
[16:27] <vila> CaMason: did you sort out how to merge the changes you wanted to reverse ?
[16:29] <CaMason> I did 'merge . -r 123..122' and that undid them nicely
[16:29] <vila> CaMason: exactly
[16:32] <CaMason> thanks. I then needed to get those changes *back* in, but on a different branch
[16:32] <CaMason> I tried 'bzr send' but the patch file didn't contain the binary data
[16:35] <gypsymauro> hi
[16:36] <gypsymauro> I'm designing my repository, there is a way to export just a subfolder of a project?
[16:38] <beuno> gypsymauro, bzr export can export a tarball of a dir
[16:47] <vila> CaMason: oh it does, but not in the human-readable part
[16:47] <CaMason> hm, well a `patch -p0 < file.patch` didn't update the binary files
[16:47] <vila> CaMason: ha no, sure, but bzr merge will ;)
[16:47] <CaMason> oh guff - would it? xD
[16:50] <CaMason> I don't see any binary data in the patch
[16:50] <CaMason> unless it's that 'begin bundle' bit at the bottom
[16:50] <vila> CaMason: it's in the bundle yes
[16:51] <vila> CaMason: in fact *all* is in the bundle, but there is a human-readable patch added for.. humans (and they don't grok binary for most of them)
[16:51] <CaMason> aha! I will retru
[16:52] <CaMason> the human readable part is huge (3000) but the bundle bit is only 4 lines
[16:52] <vila> CaMason: try 'bzr help send' for more details
[16:53] <vila> CaMason: well, if the target share some history with the source only the relevant revids have to be transmitted
[16:53] <gypsymauro> beuno:  perfect :) tanx
[16:54] <vila> CaMason: so it all depends on SUBMIT_BRANCH and PUBLIC_BRANCH and what *needs* to be sent, if the target already knows the revisions involved there is no need to transfer their *content*
[16:54] <gypsymauro> another thing, suppose I've two bzr projects , what's the best way to move a folder from a project to the other?
[16:55] <CaMason> ok, thanks :)
[17:05] <gypsymauro> I've tried to add a folder from nautilus, then I committed the change, but in nautilus I saw that subdirectories weren't added, so I added it manually now  I've a mess, then I tried do remove the folder and when I try to commit it says Conflict: can't delete zope because it is not empty.  Not deleting. \n Conflict because zope is not versioned, but has versioned children.  Versioned directory.
[17:05] <gypsymauro> any hint?
[17:08] <jkakar> jam: Hmm, interesting.  The two revisions I want to edit are -1 and -3.
[17:39] <magcius> jam, my changes to loggerhead *should* be deployed by now, right?
[17:39] <magcius> jam, if so, can you help me look at the stack trace for the OOPS IDs that I'm getting?
[18:37] <flacoste> abentley: I'm struggling with pipelines, do you think you could help?
[18:38] <abentley> flacoste: sure.
[18:38] <flacoste> abentley: i have a pipeline of one branch, and would like to create a new pipe before the current one
[18:39] <flacoste> the instructions on the wiki don't seem to work
[18:39] <flacoste> but first, i think the submit: idea is screwed
[18:39] <abentley> flacoste: which wiki instructions?
[18:39] <flacoste> http://wiki.bazaar.canonical.com/BzrPipeline
[18:39] <flacoste> "Splitting a change into two pieces"
[18:39] <flacoste> that's similar to what i want to do
[18:40] <flacoste> like i said, i think it's because its idea of submit: is broken in my config somehow
[18:40] <flacoste> if i do bzr diff -r submit: in my branch
[18:40] <flacoste> it doesn't show any change
[18:40] <flacoste> might be related to my standard bzr conf (Launchpad-style)
[18:41] <flacoste> but i don't know where to start to untangle this
[18:41] <abentley> flacoste: okay, so do you know what revision you actually want to use as the basis for the first pipe?
[18:41] <flacoste> abentley: trunk
[18:41] <flacoste> or the revision from which i branch from trunk
[18:41] <flacoste> to be more precise
[18:42] <flacoste> http://pastebin.ubuntu.com/581248/
[18:42] <flacoste> shows a bzr info in my current tree
[18:42] <abentley> flacoste: so then -r ancestor:path/to/trunk
[18:44] <flacoste> abentley: is it a known bug that remove-pipe doesn't remove the branch file (if i remove-pipe and then try to add-pipe with the same name, it fails)
[18:45] <abentley> flacoste: yes, it is, and there's the --branch option  to remove the branch file as well.
[18:45] <flacoste> abentley: -r ancestor:trunk did the right thing :-)
[18:45] <abentley> flacoste: so not a bug, a feature.
[18:46] <flacoste> well, not sure it's a feature, but at least, it's by design :-)
[18:46] <abentley> flacoste: just because you don't want the branch participating in the pipeline doesn't mean you want to destroy the branch.
[18:47] <flacoste> i can understand that point of view, although from a naive user, this behaviour was surprising
[18:47] <flacoste> s/although/as a/
[18:47] <flacoste> any way, to have submit: works as a short-hand for ancestor:.../trunk ?
[18:48] <abentley> flacoste: I guess it is, and asymmetrical too.  But I am reluctant to delete branches whithout explicit user request.
[18:48] <abentley> flacoste: you'll want to add a section to your locations.conf.  Let me work it up.
[18:48] <flacoste> abentley: i can understand, that's hard to fix, maybe just pointing that out in the user  message would make this much more friendly
[18:49] <flacoste> after remove-pipe: something like
[18:49] <flacoste> 'Leaving branch in ... Use XXX to remove"
[18:49] <flacoste> and in the error message in add-pipe
[18:50] <flacoste> anyway, just my $.02
[18:54] <abentley> flacoste: here's what you'd add to locations.conf: http://pastebin.ubuntu.com/581252/
[18:55] <abentley> flacoste: I noticed your push location was also wrong.
[18:56] <flacoste> abentley: yeah, will this fix it too?
[18:56] <abentley> flacoste: yes, it should.
[18:57] <flacoste> i put this in $HOME/.bazaar/locations.conf ?
[18:57] <abentley> flacoste: right.
[18:58] <flacoste> abentley: wouldn't that be [/home/francis/canonical/tuolumne/BRANCH/.bzr/pipes/]?
[18:58] <flacoste> since there is no .bzr/pipes in the repository
[18:58] <flacoste> BRANCH is 'dashboards' in this case
[18:59] <abentley> flacoste: According to the URLs you posted, your branch is at /home/francis/canonical/tuolumne/.bzr/pipes/dashboards
[19:00] <abentley> flacoste: no, wait.
[19:01] <flacoste> confusing bzr output i think
[19:01] <abentley> flacoste: I guess there's no indication of your CWD.
[19:01] <flacoste> yeah
[19:01] <flacoste> the branch is ~/canonical/tuolumne/dashboards
[19:01] <flacoste> ~/canonical/tuolumne is the project repository
[19:01] <flacoste> and i have generic entry in locations.conf to map to LP
[19:01] <abentley> flacoste: the branch is `pwd`.bzr/pipes/dashboards
[19:02] <flacoste> right
[19:02] <flacoste> `pwd` is a lightweight checkout
[19:02] <abentley> Right.
[19:03] <flacoste> but i should put `pwd`/.bzr/pipes in locations.conf?
[19:03] <abentley> Yes.
[19:04] <flacoste> any way, i could do this in a generic way?
[19:05] <flacoste> otherwise, i'll guess i'll have to add this whenever i have a new pipepline?
[19:05] <abentley> flacoste: to do this in a generic way, keep the branches in your normal location, and don't use reconfigure-pipeline.
[19:06] <flacoste> abentley: hmm, that doesn't work without me changing my normal location (since i don't normally use lightweight checkout)
[19:07] <abentley> flacoste: I proposed a patch to make the config system work with reconfigure-pipeline, but it is stalled: https://code.launchpad.net/~abentley/bzr/appenddir/+merge/50060
[19:08] <abentley> flacoste: of course, there's nothing stopping you from keeping lightweight checkouts in your normal branch location, in addition to the branches.
[19:09] <abentley> flacoste: I've always kept my lightweight checkouts separate, though.
[19:11] <flacoste> abentley: thanks for the help
[19:12] <abentley> flacoste: you're welcome.
[23:13] <poolie> hi all