[00:11] <lifeless> salgado-afk: I'm trying to reproduce now
=== psynaptic is now known as psynaptic|afk
[00:17]  * SamB wonders why poolie has to ASK jam if he can call him
[00:18] <jam> SamB: because it is 1.5 hours past the end of my work day
[00:18] <SamB> oh, right, work relationship ...
[00:19]  * SamB isn't used to many people in an IRC channel working for the same company
[00:19] <lifeless> more a work call
[00:19] <shikibu> I am trying to do bzr init; bzr add in a quite small directory tree, and bzr seems determined to ignore one of my directories (formassembly/). Any idea why? http://pastebin.com/d5c84f4f1
[00:19] <lifeless> many of us have relationships preceeding working at the same company, but if we're communicating about work respecting work/family balance is easy and important
[00:20] <shikibu> poolie: ?
[00:20] <shikibu> ^
[00:20] <SamB> oh, and not terribly used to people having lives ;-P
[00:21] <lifeless> shikibu: odd
[00:21] <lifeless> shikibu: what does 'bzr add formassembly' do ?
[00:21] <jam> lifeless: global ignores?
[00:22] <lifeless> shikibu: also, perhaps a global ignore as jam says
[00:22] <shikibu> lifeless: http://pastebin.com/d41406944
[00:23] <poolie> shikibu: hi; i'm on the phone to jam
[00:23] <lifeless> shikibu: cat ~/.bazaar/ignore
[00:24] <jam> lifeless: formassebly is a bzr branch
[00:24] <shikibu> not there
[00:24] <jam> shikibu: bzr status formassembly?
[00:24] <shikibu> http://pastebin.com/d515abbf0
[00:24] <lifeless> oh
[00:24] <lifeless> ls -a formassembly
[00:24] <jam> lifeless: that is my guess, at least
[00:24] <shikibu> lifeless: http://pastebin.com/d1c3ef6ca
[00:24] <lifeless> jam: I'm betting svn
[00:25] <shikibu> lifeless: http://pastebin.com/d7427da4a
[00:25] <jam> shikibu, lifeless: could be anything but "bzr status formassembly" makes it clear it is a separate project
[00:25] <jam> which is why we aren't adding it
[00:25] <lifeless> jam wins
[00:25] <jam> and I believe there is an open bug about it
[00:25] <shikibu> ah, I see. thank you@
[00:25] <lifeless> shikibu: you've bzr init'd the subdir formassembly already
[00:25] <shikibu> thank you!
[00:26] <shikibu> yes, i understand now
[00:27] <lifeless> jam: python 2.4 doesn't have SEEK_SET/SEEK_CUR, I'll just define them locally if thats ok
[00:27] <lifeless> jam: but I'll call them SUBUNIT_SET/SUBUNIT_CUR
[00:31] <jam> lifeless: or COUNT_SET/COUNT_CUR, but sure
[00:42] <poolie> lifeless: do they really have to be variables pointing to ints?
[00:55] <lifeless> poolie: well, its an enum
[01:09]  * spiv yawns
=== cprov-afk is now known as cprov
[01:22] <poolie> lifeless: that mp was pretty damn timely :)
[01:22] <poolie> it's the secret of good comedy you know :)
[01:26] <lifeless> :)
[01:37] <lifeless> spiv: ping
[01:49] <lifeless> salgado-afk: still up?
[01:52] <salgado-afk> lifeless, yes, but not for very long
[01:52] <lifeless> have you tried with bzr 1.17 or 1.16 ?
[01:52] <lifeless> do they also fail?
[01:53] <salgado-afk> just bzr 1.17
[01:53] <lifeless> and did it fail too?
[01:54] <salgado-afk> I don't quite understand your question, but locally I can't reproduce the error, either with 1.17 or 1.18dev
[01:54] <lifeless> I meanm have you tried to branch from lp with 1.17
[01:55] <salgado-afk> not sure; let me try again
[01:55] <salgado-afk> abentley did that, IIRC
[01:56] <salgado-afk> AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'
[01:56] <salgado-afk> that's what I get when branching from lp using 1.17
[01:56] <lifeless> ok
[01:56] <lifeless> does the backtrace look the same otherwise?
[01:58] <salgado-afk> I think so, let me paste it
[01:58] <salgado-afk> https://pastebin.canonical.com/20572/
[01:59] <salgado-afk> lifeless, as I mentioned earlier, my temp branch on that project looks weird.  that was the first thing I pushed on that project, and it is a launchpad branch, IIRC
[01:59] <salgado-afk> I pushed it from the DC so that I'd have something to stack on
[01:59] <lifeless> its the same in 1.17
[02:00] <lifeless> which is good
[02:00] <lifeless> thanks
[02:00] <lifeless> I hope to have something for you overnight
[02:00] <salgado-afk> lifeless, great, just let me know if there's anything else I can help with
[02:00] <spiv> salgado-afk: just checking, local and remote are both 2a in this case?
[02:00] <lifeless> don't fix it :)
[02:00] <lifeless> spiv: yes
[02:00] <spiv> Ok, good.
[02:01] <lifeless> I haven't checked if trunk's format is 2a
[02:01] <spiv> lifeless: (bzr.dev currently fails to push between CHK repos with different serializers)
[02:01] <lifeless> but it stacks ok, so I assume it is :P
[02:01] <spiv> (at least in the presence of stacking)
[02:47] <lifeless> spiv: https://bugs.edge.launchpad.net/bzr/+bug/406686
[02:47] <lifeless> and
[02:47] <ubottu> Launchpad bug 406686 in bzr "get_stream_for_missing_keys does not include inventory CHK pages." [Undecided,New]
[02:47] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/406687
[02:47] <ubottu> Launchpad bug 406687 in bzr "insert_stream doesn't check references are satisfied" [Undecided,New]
[02:48] <lifeless> spiv: mayI call?
[02:49] <spiv> lifeless: sure
[03:24] <lifeless> spiv: nosmart+lp:~salgado/canonical-identity-provider/test4
[04:04] <poolie> biab
=== _thumper_ is now known as thumper
[06:25] <spiv> lifeless: curiously, your merge proposals (and only yours) display in mutt with ^M at the end of every line of the attachment.
[06:26] <lifeless> \o/ evo
[06:26] <lifeless> its probably being correct
=== MT- is now known as MT
=== MT is now known as MT-
[06:40] <fullermd> spiv: ping
[06:40] <spiv> fullermd: pong
[06:40] <fullermd> spiv: Did you ever find anything on bug 389413?
[06:40] <ubottu> Launchpad bug 389413 in bzr "ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked running diff across hpss" [High,Confirmed] https://launchpad.net/bugs/389413
[06:40] <fullermd> I just had a coworker hit what looks like it with merge.
[06:40] <spiv> fullermd: it's probably quite shallow, but I just haven't got it it.
[06:41] <spiv> Presumably a lock isn't being held long enough.
[06:41] <fullermd> 'k
[06:42] <spiv> fullermd: if the traceback isn't obviously the same, feel free to add it to the bug, though.
=== MT- is now known as MTeck
[07:17] <AfC> Is there a diffstat equivalent in Bazaar land?
[07:18] <mwhudson> AfC: we still have diffstat ?
[07:18] <lifeless> there is a diffstat plugin
=== MTeck is now known as MT-
[07:18] <AfC> I'm not even sure if it means anything, but it seems the closest I've come across to an abstract quantification of the size of a delta
[07:18] <lifeless> also bzr diff | diffstat :P
[07:18] <AfC> lifeless: oh, it's a command? Sorry didn't know that.
[07:18]  * AfC goes a hunting
[07:19] <AfC> lifeless: so, what would a bzr diffstat plugin be doing that bzr diff | diffstat doesn't? Is that plugin something I should go find?
[07:21] <lifeless> AfC: its easier for folk on windows
[07:21] <AfC> {snort}
[07:21] <AfC> ah
[07:22] <AfC> right
[07:25] <lifeless> it can also do things like hook into the commit template, I suppose
[09:45] <ronny> does bzr have something like keywords that get expaneded to the current data
[09:45] <fullermd> Sorta kinda.
[09:46] <fullermd> Alternately, "Yes, with a plugin, but they mostly don't work, and where they do, they're inconvenient to enable."
[09:48] <ronny> hmk, i'll just add some calls to the bzr version info thing then
[10:04] <ronny> hmm, works fine
[10:32] <ronny> whats the propper way to merge, if a file got created independ in 2 branches
[10:32] <ronny> (it created a .bzrignore.moved file)
[10:34] <bialix> merge old a new file by hands, select wich file history to stay, delete other file and resoove conflict
[10:38] <ronny> ok
[10:48] <sender> anyone an idea of a way to integrated bzr and mantis bugtracker? that bugtracker tab under settings, looks quite promising :)
[10:49] <bialix> it depends on what you mean by "integrate"
[10:50] <sender> bialix: tx, assign a bugnumber to a commit for example
[10:50] <bialix> ah, this should be very easy
[10:51] <bialix> can you show the typical URL to your bugs?
[10:52] <sender> something from the mantis website itself, this is the url to view a certain bug: http://www.mantisbt.org/bugs/view.php?id=7721
[10:52] <sender> bugnumber: 0007721
[10:53] <bialix> so you can assign
[10:54] <bialix> bugtracker_mantis_url = http://www.mantisbt.org/bugs/view.php?id={id}
[10:54] <bialix> and then use
[10:54] <bialix> bzr ci --fixes mantis:7721
[10:55] <sender> great!
[10:55] <bialix> qlog can show you bugs assigned to revisions
[10:56] <bialix> hmm, it seems qlog does not support mantis yet
[10:56] <bialix> I'll add such support
[10:56] <sender> wow that's great
[10:57] <sender> the abbreviation is configurable? "mantis:" could be "bug:" or "m:"?
[10:58] <bialix> it should be the same you put in bugtracker_???_url name
[11:00] <sender> nice. bzr, plugins and support keeps amazing me =)
[11:13] <lifeless> jelmer: I'm doing a talk on subunit at slug tomorrow, ok to mention samba as a user?
[11:19] <sender> bialix: after commit --fixes, I don't see any info on this show up in bzr log, is this correct? bzr qlog crashes (probably the same error that you saw - I guess I don't need to report it?)
[11:19] <bialix> plain log does not show this info, yes
[11:20] <bialix> try to update qbzr from trunk branch
[11:20] <sender> Is there an other way to see that the bugfix is attached to the commit?
[11:20] <sender> ok
[11:20] <bialix> can you pastbin qlog error anyway?
[11:21] <sender> http://pastebin.com/m57605735
[11:23] <jelmer> lifeless: Hi
[11:23] <bialix> sender: no it's different error maybe
[11:23] <jelmer> lifeless: Yes, of course :-)
[11:23] <bialix> sender: try to update your qbzr from trunk and say me if my change helps
[11:24] <bialix> sender: but it smells like new bug
[11:24] <bialix> sender: will be nice to file it as bug report
[11:25] <lifeless> jelmer: whats the name of your C test library?
[11:25] <jelmer> lifeless: libtorture
[11:25] <sender> bialix: qlog from trunk looks perfect
[11:25] <jelmer> lifeless, it's not really usable standalone though, and quite specific to samba at the moment
[11:25] <lifeless> yeah, I know
[11:25] <bialix> sender: file a bug please, mention that qlog crashes when bug_url is unknown
[11:26] <sender> no errormessage and a nice red bar to show bug id, great =)
[11:26] <sender> ok i will, can i retrigger? just remove bugtracker setting?
[11:28] <bialix> no, you have to comment line 59 in qbzr/lib/logmodel.py
[11:29] <bialix> this one: r'|bugs/view.php\?id='      # Mantis bug tracker URL
[11:33] <sender> bialix: if I remove the mantis url from settings, the new qlog still works. commit --fixes refuses. Seems like "qlog crashes when bug_url is unknown" is not the actual bug?
[11:34] <bialix> no
[11:34] <bialix> sender: you have to comment line 59 in qbzr/lib/logmodel.py
[11:34] <bialix> this one: r'|bugs/view.php\?id=' # Mantis bug tracker URL
[11:34] <bialix> qlog does not use bugtracker_XXX_url settings at all
[11:35] <bialix> qlog using internal regexp to parse final bug url
[11:35] <bialix> this is what I mean by bug_url is unknown
[11:35] <bialix> unknown to qlog regexp
[11:36] <bialix> sender ?
[11:36] <sender> yes bialix
[11:36] <bialix> sender: can you test with commented regexp?
[11:36] <sender> yes, def, jst a sec
[11:36] <bialix> ok
[11:37] <sender> bialix: no crash, just no "bug tag"
[11:37] <bialix> hm
[11:38] <bialix> oh
[11:38] <bialix> I know
[11:38] <bialix> recently Gary fixed bug around this feature
[11:38] <fullermd> Darn those people sneakily fixing bugs!
[11:38] <sender> :)
[11:39] <bialix> fullermd: it was actually different bug!
[11:39] <fullermd> If you fix a bug accidentally while fixing another bug, is the bug fix a bug?
[11:40] <sender> ghehe
[11:42] <bialix> err, no
[11:42] <bialix> Gary fixed bug with not very clear symptoms, and in fact he has fixed 2 bugs
[11:42] <fullermd> I think it is.  Luckily, it's easy to fix; you just say "Oh, yeah, I meant to do that".
[11:43] <bialix> or maybe this new bug symptom makes those symptomps more clear
[11:43] <bialix> anyway!
[11:43] <bialix> ta-da!
[11:43] <bialix> and everything worked!
[11:43] <bialix> :-0
[11:47] <sender> great, btw I installed mantis on localhost, and the url for bugs is: http://localhost/view.php?id=1 so without '/bugs/', it seems that mantisbt.org is the exception
[11:54] <konnertz> hi. Pls how to find out the central repository of a checkout?
[11:55] <sender> konnertz: try bzr info
[11:55] <sender> bialix: should: "http://bazaar-vcs.org/3rdPartyTools#Integrated Bug Trackers" be updated with LP, Bugzilla, Redmine, Sharepoint, Fogbugz, Roundup and Mantis?
[11:56] <konnertz> ok sender thx
[12:00] <sender> bialix: I see I can edit the page, can I add those?
[12:07]  * bialix back
[12:07] <bialix> sender: um?
[12:08] <bialix> sender: about localhost: ok, so my regexp is wrong
[12:08] <sender> bialix: but still i got the bug tag in qlog
[12:09] <bialix> sender: about 3rdPartyTools: I don't think qlog support does count there
[12:10] <bialix> sender: I don't understand you, it won't work once you setup different url
[12:11] <sender> bialix: ok will test again
[12:12] <bialix> sender: on commit bzr store exact URL as part of revision metadata
[12:12] <bialix> you can see it in qlog revision details window (bottom left)
[12:16] <sender> ok without the correct regexp I don't see the red tags, but the urls are in (revision details window)
[12:16] <sender> changing the regexp to r'|view.php\?id=' makes those visible
[12:17] <sender> btw it's possible to commit with --fixes mantis:2 eventhough bug nr 2 doesn't exist. is this intended?
[12:17] <fullermd> --fixes doesn't _do_ anything with the bug tracker.  It just saves a URL along with the rev for reference.
[12:19] <sender> fullermd: understood, I guess thatdistributed means
[12:19] <sender> being able to work without connection to the bugtracker (sorry for the newline)
[12:19] <fullermd> Well, not just that...  who knows how $RANDOM_BUGTRACKER works.  How could bzr _tell_ whether the bug existed?
[12:20] <fullermd> (first, you embed an HTML parser...   then an AI engine...)
[12:21] <sender> fullermd: check for 200OK?
[12:21] <sender> fullermd: AI enigine would be nice anyway ;)
[12:21] <fullermd> That wouldn't help.  The bug tracker will return a "WTF?  I don't know what that bug is" page, but it's still a HTML page that's HTTP 200 OK
[12:23] <sender> fullermd: ok that should be part of the bugtracker specific settings then, but def. nasty to implement
[12:25] <fullermd> Yeah.  VERY nasty to implement, exponentially so to maintain.  And what if it needs authentication?  Session state?  etc.  It's an endless garden path.
[12:27] <sender> :) btw would it in a way be possible to show the diff(s) along with the bug in mantis?
[12:28] <fullermd> That would be going the other way; teaching mantis about bzr.
[12:29] <sender> yeah, too bad bzr log doesn't seem to support bugnumbers, or am I missing something?
[12:30] <bialix> you can have more than one revisions with the same bug url
[12:30] <sender> bialix: is there a way to enlist them with log?
[12:31] <bialix> I don't know. fullermd, you know almost everything, what you say?
[12:33] <fullermd> I'm not aware of one offhand.
[12:33] <fullermd> I never use --fixes though, so I'm not much of an authority on it.
[12:34] <bialix> right. I've started to use --fixes heavily after I've started to use QBzr
[12:35] <bialix> QBzr has full support: in qcommit you can easily provide bug url, and then see it in qlog
[12:35] <bialix> IIRC this bug url feature was introduced in bzr core to use with lp as primary target
[12:36] <fullermd> In a quick look around, the only place I see it showing up through the CLI is the long-form testament.
[12:36] <fullermd> It's probably just gotten at the API level anywhere that actually uses it currently.
[12:37] <fullermd> So, as soon as someone reimplements bzrlib in a sensible language like perl...   O:-}
[12:38] <bialix> lol
=== mrevell is now known as mrevell-lunch
=== salgado-afk is now known as salgado
=== mrevell-lunch is now known as mrevell
[13:07] <salgado> lifeless, how can I test your fix for that bug we were debugging yesterday?
=== verterok_ is now known as verterok
=== JamalFanaian|afk is now known as JamalFanaian
=== oubiwann_ is now known as oubiwann
[15:39] <dvheumen> Hi, does anyone know which sentence is (more) correct? "warning: \'--allow-writes\' enables unauthenticated ' \
[15:39] <dvheumen>                 'write access to anyone with network access to the server.
[15:39] <dvheumen> woops, sorry
[15:40] <dvheumen> ... enables unauthenticated writes access {to,for} anyone with network access to the server ... (Which is better, 'to' or 'for'?)
[15:41] <bob2> by
[15:42] <dvheumen> bob2: by?
[15:46] <bob2> enables unauthenticated write access by anyone with network access
[15:56] <theAdib> hello all,I am working on a project where I have to program on a win32/linux/mac box. I tried bazaar on my web server using ftp. Bazaar fails updating: FTP temporary error: 451 /repository.bzr/TDD/.bzr/repository/upload/eexq0mvoqcyo
[15:56] <theAdib> zaxulmqz.pack: Append/Restart not permitted, try again. Retrying.
[15:56] <theAdib> and then aborts after 3 failures. I can not change the settings in the ftp server (is part of the webhoster)
[15:57] <theAdib> Do you have a suggestion how to work using bazaar? (My win32 and linux is on one computer)
[15:58] <bob2> they don't provide ssh access?
[16:00] <theAdib> bob2, no, they don't
[16:10] <SamB> theAdib: break out your *old* computer
[16:10] <SamB> use it as an SSH server
[16:12] <theAdib> any way to use the ftp server as a collector for patch-sets and merge them back in an intelligent way?
[16:21] <theAdib> is it possible to put the bzr-repository on an usb stick? And then move this from computer to computer?
[16:25] <bob2> sure
=== beuno is now known as beuno-lunch
[16:54] <sigmonsays> Does anyone know what bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKintPack6 (bzr 1.9)\n' can be avoided?
[16:54] <sigmonsays> s/what/how/
[16:55]  * sigmonsays mumbles, back in his day you used to cvs checkout without a login. Now I need to give them a shared key, my e-mail and make an account in their system
[16:55] <sigmonsays> oh, and install their crappy RCS command
[16:55] <sigmonsays> that doesn't work...
[16:57] <sigmonsays> this is rediculous
[17:01] <Tak> sigmonsays: what version of bzr do you have?
=== KX is now known as Xavura
[17:01] <sigmonsays> Bazaar 1.5
[17:02] <sigmonsays> they should seriously fix their crap if i'm forced to use it
[17:03] <sigmonsays> this just pisses me off
[17:03] <Tak> so...you have bzr 1.5, and it can't understand a bzr 1.9 format
[17:03] <Tak> seems pretty straightforward
[17:04] <Tak> who's "they", and how are they forcing you to use it?
[17:04] <sigmonsays> everyone
[17:04] <sigmonsays> jumpin through hoops just to get some code
[17:05] <sigmonsays> git just works
[17:05] <sigmonsays> none of this version crap
[17:05] <sigmonsays> no account on launchpad
[17:05] <sigmonsays> no shared key uploaded
[17:05] <sigmonsays> no e-mail given
[17:05] <sigmonsays> wtf is all that
[17:05] <sigmonsays> they want some piss and blood too?
[17:06] <Tak> git works? there must be a new release...
[17:06] <Tak> you don't have to have a launchpad account to checkout code
[17:08] <Tak> what you apparently need is a version of bzr that's less than 15 months old
[17:09] <ToyKeeper> D'oh.  I still can't 'bzr diff -r parent:' even though 'bzr diff -r submit:' works fine.
[17:12] <Tak> although it would be nice if lp allowed one to grab a tarball of a particular revision
[17:15] <jelmer> Tak: bzr export -r<revision> lp:bzr foo.tar.gz
[17:15] <jelmer> with the last two arguments swapped, sorry
[17:16] <Tak> yeah, but I mean from the web ui
[17:16] <jelmer> ah, right
[17:16] <jelmer> I think there was some work happening in loggerhead to support that
[17:16] <jelmer> Not sure if it's landed yet though, and/or if it is enabled on launchpad
[17:18] <Tak> I can't find it anywhere on launchpad, although it could just be some place I haven't thought to look
=== mrevell is now known as mrevell-dinner
=== vxnick-AFK is now known as vxnick
[18:31]  * kfogel is away: kfogel-food
=== kfogel is now known as kfogel-food
[18:36] <askogrand> This might seem like a silly question, but with bazaar can someone check out a single file?
[18:36] <askogrand> as opposed to a folder.
=== beuno-lunch is now known as beuno
[18:40] <bob2> no
[18:48] <askogrand> is there any version control system that will?
[18:48] <bob2> svn
[18:52] <captainc> Alright, I downloaded the bzr windows installation package and its giving me errors about plugins that are supposed to be in my local python site-packages directory. should i uninstall and reinstall in a different way?
[18:56] <Raim> bob2: svn does not support checkout of single files, only unversioned 'svn cat $URL'
=== kfogel-food is now known as kfogel
[20:22] <captainc> How do I fix or work around this win32 symlinks issue?
[20:23] <captainc> without cygwin
[20:30] <phinze> hi folks, can someone point me in the direction of (or just give your own offhand) definition for "upstream" and "downstream" in the VCS domain?
[20:30] <phinze> is upstream towards trunk and downstream towards the most remote fork?
[20:30] <phinze> or the other way around?
[20:32] <phinze> actually, just found this, which helped: http://strategiesforsustainability.blogspot.com/2005/10/upstream-vs-downstream.html
[20:32] <Linkadmin> is there a way to configure a plugin against a branch instead of in ~/.bazaar/ ? I'd like to set up the bzr-email plugin to send an email to the dev mailing list on update without making all users install/configure the plugin in their homedirs...
[20:34] <phinze> Linkadmin: you can install the plugin systemwide on your central server and then configure that branch to send emails; let me see if i can find a link that describes that
[20:34] <Linkadmin> i've installed it system-wide already. Wasn't able to find docs on binding a plugin to a branch. That would be *much* appreciated
[20:35] <phinze> ah ok
[20:38] <phinze> so bzr help email is telling you to set post_commit_to and post_commit_sender ... i'm not completely sure but i think you should be able to set those in .bazaar/branch/branch.conf
[20:38] <phinze> s/.bazaar/.bzr/
[20:40] <Linkadmin> tried that on my local branch then bzr commit resulted in a pointlessCommit. I'll try on the central branch instead
[20:40] <phinze> hah, that's a sassy error
[20:41] <Linkadmin> lol yes
[20:42] <phinze> Linkadmin: the other thing to look into would be https://launchpad.net/bzr-hookless-email
[20:42] <phinze> i used that to some success for awhile
[20:42] <phinze> it's nice because it doesn't have to be tied to a particular branch
[20:43] <Linkadmin> it appears the branch.conf change in the central branch on the server worked  :D
[20:43] <Linkadmin> i'll bookmark the other one too, thanks a ton!~
[20:44] <phinze> awesome; good to hear -- i was always wondering whether bzr-email could worth that way :)
[20:45] <Linkadmin> yeah i was really worried that it wouldn't hehe.
[21:24] <lifeless> moin
=== mwhudson_ is now known as mwhudson
=== fta_ is now known as fta
[22:06] <flvr8> hey, what's the proper thing to do with uncommitted trunk changes before doing a bzr switch to a branch? committing them locally fails (switch complains). we have a central repo, so there'd be nowhere to push them otherwise
[22:07] <lifeless> flvr8: do you want them committed to trunk?
[22:08] <flvr8> nope. (actually i'm asking on behalf of one of the guys in my team). typically the situation is he's working on a feature that'll end up in trunk, but he's not ready to commit. and some fire comes up on production that requires a change to the branch
[22:08] <lifeless> bzr shelve --all
[22:08] <lifeless> when hes done, bzr unshelve
[22:09] <flvr8> excellent. thanks
[22:33] <lifeless> moin jam
[22:33] <abentley> lifeless: bzr-pipeline has that built in-- every branch has a shelf, and switching shelves and unshelves changes.  It works pretty nicely, and I'd like to have it in core.
[22:34] <lifeless> abentley: Something I have with looms that I don't with regular branches is shelve-in-one-place, unshelve-in-another
[22:34] <jam> morning lifeless
[22:34] <jam> evening abentley
[22:35] <abentley> jam: evening.
[22:35] <lifeless> abentley: I really like that; its for moving changes across branches (similar to switch merging)
[22:36] <lifeless> abentley: I think both cases are useful; I agree that having a solid answer to 'stop working on this bit now, but its not ready to commit' is needed, I'd also like to have an easier story for 'move this bit elsewhere' - which is currently 'switch elsewhere' for me
[22:36] <lifeless> abentley: if we can satisfy both use cases in core I'll be ecstatic, and change loom to match the idiom
[22:37] <abentley> lifeless: We already have merge --uncommitted and switch for the second case.  Why don't they satisfy?
[22:38] <lifeless> abentley: merge --uncommitted isn't as interactive as shelve; it doesn't satisfy the 'get one hunk case'. I currently do that by 'shelve; select all but the bit I want to move elsewhere', then either switch or merge --uncommitted
[22:38] <lifeless> then an unshelve
[22:38] <abentley> lifeless: merge --uncommitted -i is exactly as interactive as shelve.
[22:39] <lifeless> oh thats landed. Nice one1
[22:39] <lifeless> s/1/!
[22:40] <lifeless> so, in pipeline, how do you move an uncommitted change to the pipe before/after ?
[22:40] <abentley> lifeless: Yep.  I was also thinking about supporting merge --shelf.
[22:41] <abentley> lifeless: I move changes with standard switch, or with merge --uncommitted PIPE.
[22:41] <lifeless> abentley: salgado's bug yesterday, was it affecting the lp puller/scanner/review stuff?
[22:41] <lifeless> abentley: I thought you said that switching shelves first ?
[22:42] <abentley> lifeless: I was simplifying.  "switch-pipe" shelves first.
[22:42] <lifeless> jam: as you'll have finished work when I get these tweaks done, is there more after them? and do you want a re-review, or can I just grab a local tz-er for an incremental ok?
[22:43] <lifeless> abentley: ah, ok.
[22:43] <abentley> lifeless: I would expect salgado's bug to affect the puller, but I don't actually know.
[22:43] <lifeless> abentley: ok. His bug is a bug in the remote streaming code, the branch itself is intact
[22:43] <jam> lifeless: pretty sure an incremental is fine
[22:43] <lifeless> if the puller is using file: or http: urls it won't be affected
[22:43] <lifeless> jam: thanks
[22:43] <jam> I don't remember any major review that was needed
[22:44] <abentley> lifeless: Those pulls use http IIRC, so we might be okay.
[22:44] <lifeless> cool
[22:44] <lifeless> I won't make a lp task for the bug at this point then
[22:45] <abentley> hmm, no, the scanner uses http.  I bet the puller uses file:  mwhudson?
[22:45] <lifeless> so, you'd like to add per-branch shelves to core?
[22:45] <abentley> lifeless: Yes.
[22:45] <lifeless> along-with or replacing per-tree shelves?
[22:46] <lifeless> It seems like along-with will add some complexity to the ui and how to explain/work with shelves
[22:46] <abentley> lifeless: along-with, I think.  I tried to replace shelf with bzr-pipeline, but it wasn't really nice.
[22:47] <lifeless> by replace with bzr-pipeline, you mean something like doing a commit on switch-pipe (from), and an uncommit on switch-pipe (to) ?
[22:48] <abentley> lifeless: I was trying to unify shelves and (threads|pipes) into a single concept, but it didn't really work out.
[22:48] <lifeless> ah interesting
[22:49] <lifeless> so I was thinking during this conversation that for a branch, just doing a commit on the tip is ~= shelve
[22:49] <abentley> lifeless: You can do "add-pipe -i --no-switch" to get an effect similar to "shelve"
[22:49] <lifeless> when the use case is that you're getting rid of the attached tree (due to switch), and implicitly popping it off when the user returns to the branch
[22:50] <lifeless> but thats likely going to surprise users that attach to the branch with a checkout, so its probably just a completely crack idea
[22:52] <mwhudson> abentley: yes
[22:53] <mwhudson> (well, it used lp-hosted/lp-mirrored, which backs onto a local transport)
[22:53] <lifeless> abentley: so, +1 on some way to stash changes for a branch when there is no tree; I think users wanting to bzr switch will appreciate this a lot
[22:53] <abentley> lifeless: I think you *could* do it as a commit, as long as you record the head somewhere other than last_revision.  Though you lose some of the potential for recording missing files, etc. that shelves have.
[22:53] <lifeless> abentley: I'm not sure about the mechanism of shelf-per-branch, rather than (say) shelves-named-by-branches-in-the-tree
[22:54] <lifeless> abentley: what do shelves do for missing files?
[22:55] <lifeless> abentley: my concern about the mechanism is just ui complication/confusion. It would be good to get a few possible mechanisms under evaluation (something it sounds like you've been doing already) and do set based design on them
[22:55] <abentley> lifeless: Being based on PreviewTree, shelves can represent basically any working tree state.  So if you added a file-id but not a file, you could shelve that.
[22:56] <abentley> lifeless: But I said "potential", because most of our code, like merge, ignores unversioned files.
[22:56] <lifeless> abentley: that makes me start speculating about having a kind of 'missing' in inventories ;)
[22:58] <abentley> lifeless: The shelf on pipes only has space for a single set of changes, and it seems to work out alright.  Maybe I should see about making shelve/unshelve actually use pipes.
[23:00] <abentley> lifeless: That would give us a single concept, but retain the specific shelve/unshelve UI.
[23:01] <lifeless> so, in a non-pipeline, shelve would be as it is, in a pipeline it would add pipes ?
[23:06] <lifeless> abentley: I think there are two broad questions: does shelve need a supercapability over commit? If yes, then we have to use shelve storage. If no we can look at temporary commits.
[23:07] <lifeless> Secondly, what places do we need to be able to shelve things *to* - both for users comfort and tools like pipe/loom/bzr-explorer
[23:19] <abentley> lifeless: sorry, on phone.
[23:20] <lifeless> abentley: no worries, just finishing overnight mail+reviews anyhow