[06:11] <GungaDin> if I've merged something (still haven't committed!!!)  and I'd like to reverse this operation and do a different merge, how can I do that?
[06:11] <bob2> revert
[06:12] <GungaDin> but hasn't the history been updated yet?
[06:12] <bob2> not until you commit
[06:14] <GungaDin> cool
[06:14] <GungaDin> thx
[06:16] <RAOF> bzr is all about not doing things you don't want to do. :)
[06:18] <fullermd> Where's the "no-taxes" plugin then?
[07:41] <vila> hi all !
[07:42]  * fullermd waves at vila.
[09:59] <masklinn> hello, is there a way to edit history in bazaar in order to fix a previous (broken, but not yet published) commit? In mercurial I'd use mq, qimport everything down to the faulty commit, qpop and edit my broken commit (or merge patches, whatever), in git I'm sure I'd find a way, but in bazaar I haven't found any paths so far. Loom is billed as an equivalent to MQ, but looks very complex, apparently modifies the repository format (is it still possible 
[10:00] <masklinn> push to the regular, old format? Or for loom-less people to get non-loomed revisions as it is with hg mq?) and I haven't found any instruction on importing "normal" bzr revisions into looms and exporting them back in bazaar.
[10:02] <masklinn> So... is there anything I missed? How do you handle the case where you performed a broken commit and only realize it 5 commits later?
[10:03] <bob2> you can uncommit
[10:03] <beuno> or use bzr-rewrite
[10:03] <bob2> or you can branch from before the problem and manually commit new changes
[10:03] <bob2> or use bzr-rewrite
[10:03] <bob2> aka bzr rebase
[10:04] <Peng> masklinn: Mostly we just commit a fix. :P
[10:04] <masklinn> I don't want to uncommit, first uncommit is broken on my mac, second that means I have to manually store 5 different log messages in some kind of text file so I can re-commit later
[10:04] <masklinn> bzr-rewrite sounds interesting
[10:04] <masklinn> thanks
[10:04] <bob2> depends what broken means, too
[10:04] <masklinn> peng, I'd do that if the revisions were already published, but the history is still fully local so it's a waste to have broken revisions in there when I'm still in a position to amend them without anybody knowing
[10:05] <bob2> if it's "bug in the code", just fix it like Peng said
[10:05] <bob2> if it's nuclear launch codes, then put more effort in
[10:05] <Kinnison> Or you put up with the fact that you got a broken commit; fix the issue on head, and move on, having learned to be more careful in future :-)
[10:05] <vila> masklinn: if uncommit is broken on your mac (how so ?), please a file a bug
[10:05] <masklinn> vila: it locks up 9 times out of 10, no error message no nothing, and I have to C-c, break the lock, update and I lose all the changes in the tentatively uncommited commit
[10:06] <vila> masklinn: no messages even in .bzr.log ?
[10:06] <masklinn> vila: I don't know, I'll have to check next time it happens
[10:06] <masklinn> vila: never really wondered about the logfile
[10:06] <vila> masklinn: .bzr.log should still contain your old attemps, no need to wait :D
[10:07] <masklinn> vila: yeah but I tend to create and delete lots of clones, so I'm not sure I still have repositories where I did it. I tend to just avoid the operation these days
[10:09] <vila> masklinn: ok, then keep in mind that many people use uncommit on mac (myself included) and nobody ever report problems there, so presumably something is special in your config
[10:09] <masklinn> vila: i'm sure that's the case, which is why I specified it was broken on *my* machine, not in general ;)
[10:10] <vila> masklinn: if there is a bug, we want it to be fixed ;)
[10:10] <masklinn> yep, I'll check the log next time I forget myself and try an uncommit
[10:11] <j^> why does bzr use so much memory if i checkout an lp repository without account?
[10:11] <j^> i.e. bzr branch lp:bzr
[10:11] <j^> 595m 421m 2280 D  1.0 42.1   3:27.54 bzr
[10:14] <Peng> Yikes.
[10:21] <gerard_> hey
[10:42] <gerard_> jam: did you see the latest changes to my branch?
[10:42] <gerard_> I'm happy with it now :) ;)
[10:45] <masklinn> vila, where's the bzr log supposed to be?
[10:45] <bob2> ~/.
[10:46] <masklinn> oh, not in the repo root or .bzr?
[10:46] <vila> masklinn: 'bzr version' should tell you
[10:46] <vila> gerard_: jam in in Chicago, he's sleeping :D
[10:47] <fullermd> Yeah.  Nobody in this TZ would be awake at this hour; that would be crazy.
[10:47] <vila> j^: which bzr version are you using ? bzr-2.1 has fix a few related bugs
[10:48] <gerard_> vila: ah, hehe
[10:48] <vila> yeah no *average* body :D
[10:48] <vila> only people like cops, fire workers and the like, plus of course the bad guys...
[10:49] <vila> did I miss some category ? :D
[10:50] <fullermd> Well, I'm not a cop, I'm not a fire worker, I...   umm....
[10:50] <fullermd> Well, no, I guess that's all the categories   :p
[10:50] <vila> hehe
[10:51] <masklinn> vila, well there does't seem to be anything of note in the logs: http://pastebin.com/d7e2a0cf0
[10:51] <masklinn> Is there a way to turn the log's verbosity to 11 or something? I don't see anything in the docs
[10:52] <vila> masklinn: you meant C-c or you really did C-z ?
[10:53] <masklinn> I really did C-z, C-c didn't do anything, and neither did C-d
[10:53] <masklinn> The above revision(s) will be removed.
[10:53] <masklinn> Are you sure [y/N]? y
[10:53] <masklinn> ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^Z
[10:53] <masklinn> [1]+  Stopped                 bzr uncommit
[10:53] <vila> C-z suspend the process and put it in the background, you leave bzr no chance to clean up anything
[10:53] <masklinn> well to kill it I used a regular kill, not a kill -9
[10:54] <masklinn> so theoretically it should have given bzr the ability to do something, right?
[10:55] <vila> weird, what kind of setup are you using ? A bound branch ? The warning about the working tree out of date may be due to the break...
[10:55] <vila> masklinn: well, yes
[10:55] <masklinn> yeah the warning is due to the break, that's not an issue (the second command is mainly to show that there was nothing after the uncommit)
[10:55] <fullermd> Well, if ^C (with at least a few seconds) didn't interrupt it, it's stuck in the kernel somewhere, so it would never get a chance anyway.
[10:55] <masklinn> it's a standalone
[10:55] <vila> masklinn: what bzr version are you using ? (I'm pretty sure the recent ones always output that in the log)
[10:55] <masklinn> vila: it's a standalone tree
[10:56] <masklinn> 2.0.4 from macports
[10:56] <masklinn> Bazaar (bzr) 2.0.4
[10:56] <masklinn>   Python interpreter: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python 2.6.4
[10:56] <masklinn>   Python standard library: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
[10:56] <masklinn>   Platform: Darwin-10.2.0-i386-64bit
[10:56] <masklinn>   bzrlib: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/bzrlib
[10:56] <vila> !paste
[10:57] <vila> masklinn: where is your repo ? Local ? http ? bzr+ssh ?
[10:57] <vila> masklinn: mounted NFS ?
[10:57] <masklinn> local fs
[10:58] <masklinn> freshly cloned from another local repo
[10:58] <vila> masklinn: so you don't use shared repos ? (You should give it a try if you use many branches that share history)
[10:59] <masklinn> vila: I sometimes do, but I didn't on that project. And we have... issues with shared repos (the remote repositories are in a pretty old format, so things don't work out well when trying to push or push shared repos to lp)
[11:00] <Peng> ...Huh? How would shared repos make a difference there?
[11:00] <masklinn> you tell me
[11:01] <masklinn> bzr whines about incompatible repository formats
[11:01] <masklinn> and lp then tells me that the repo I just pushed is broken
[11:01] <Peng> It's notable that "bzr branch" uses the source branch's format by default, but the shared repo's format if you're in a shared repo (obviously), but it's not hard to keep that straight.
[11:01] <vila> Peng: I didn't way they were related, just mentioning them
[11:02] <Peng> vila: Err, sorry. I was just replying to masklinn, not you.
[11:02] <vila> Peng: no worries ;D
[11:03] <vila> masklinn: I agree with Peng, most probably you ran into bzr forcing the default format to be 2a
[11:03] <masklinn> Peng: yes, and the shared repo is created using 2a by default, and by the time i realized that I was basically hosed. And I'm not even clear on which format I should be using locally to keep things straight, as the repo names on the CLI and the ones given by error messages are basically unrelated
[11:03] <vila> masklinn: have a look at the upgrade guide: http://doc.bazaar.canonical.com/latest/en/upgrade-guide/index.html
[11:03] <masklinn> (I'm not even sure the remote repo's format is compatible with shared repositories)
[11:04] <vila> masklinn: I'd be suprised if you use a format that doesn't support shared repos
[11:04] <masklinn> vila: might be possible at some point, but the project is pretty big, and e.g. ubuntu 8.04 doesn't ship with 2.0, so for now it's not upgraded
[11:04] <Peng> It would have to be horrifically old, or broken, to not support shared repos. Besides, what matters is the local format.
[11:04] <vila> masklinn: ok, let's put that aside for now then
[11:04] <fullermd> I'd be well beyond surprised.  all-in-one formats are *OLD*.
[11:05] <vila> masklinn: how big is your working tree ?
[11:05] <masklinn> villa: the project/branch in question is https://code.launchpad.net/~openerp/openobject-addons/5.0 (warning: humongously huge)
[11:05] <masklinn> vila: .bzr is 93MB, total WC is 160MB
[11:05] <vila> masklinn: how many files ?
[11:06] <masklinn> vila: I fear my bzr-fu and terminal-fu are too weak to know, how can I check?
[11:06] <vila> I wonder if you may be missing some progress report and if bzr is actually taking longer than usual to finish the uncommit
[11:07] <vila> find . | ec -l
[11:07] <masklinn> vila: I don't think so, in the past I let it run 30mn+, never saw any progress
[11:07] <vila> find . | wc -l
[11:07] <Peng> Or "bzr inventory | wc -l".
[11:07] <vila> wow, 30mn is indeed far too long
[11:07] <masklinn> vila: find . reports 5722, bzr inventory reports 5689
[11:08] <vila> can you pastebin the output of 'brz info -v' ?
[11:08] <vila> masklinn: wow, 33 unknown files ? Or are there some *~n~ files ?
[11:08] <masklinn> vila, wouldn't those be the files in .bzr?
[11:09] <vila> masklinn: oh sure
[11:09] <Peng> Wow, the remote branch is rich-root-pack, so you actually could use 2a locally, though converting between them takes a couple seconds.
[11:09] <Peng> However, you can't *stack* between them, and that's probably what's freaking Launchpad out.
[11:09] <vila> bug 33 sounds a bit high, ha no, the repo is there
[11:09] <Peng> \o/
[11:09] <vila> grr *but* 33
[11:11] <vila> ubottu: your humour is thick
[11:11] <masklinn> vila: http://pastebin.com/d78ba2197
[11:11] <masklinn> apparently something is a bit broken after the uncommit
[11:12] <masklinn> running a bzr check
[11:12] <fullermd> That probably means the uncommit did its job on the branch, and failed trying to do stuff in the working tree.
[11:12] <fullermd> That's consistent with stat bleating about needing 'update' too.
[11:12]  * vila agrees with fullermd 
[11:13] <masklinn> fullermd: I did an update after that, so the working tree should be in sync
[11:13] <vila> after what ?
[11:13] <fullermd> And doing stuff in the WT does OS locks last I checked, which is also the most likely place for uncommit to lock itself up inside the kernel.
[11:13] <masklinn> after it asked me to bzr update
[11:13] <masklinn> I bzr broke-lock and bzr updated
[11:13] <vila> yeah, so something was already broken there probably
[11:14] <vila> fullermd: OS locks are broken in OSX ? As much as in BSD ? :-D
[11:14] <masklinn> well the original repo I cloned from (the one without/before bzr uncommit) seems ok
[11:15] <Peng> Sure, working tree nonsense won't break the branch or repo.
[11:15] <Peng> Well, maybe, if you somehow commit something horribly wrong, but that's difficult.
[11:16] <vila> masklinn: side-note: since you already use a rich-root-aware format, migrating to 2a is easier
[11:17] <vila> Peng: like what ? If we can commit it we can uncommit it :D
[11:17] <masklinn> easier for me, but not easier for the project as a whole, and it doesn't solve lp freaking out everytime a bee flies near the window
[11:18] <vila> masklinn: easier compared to people using a non rich-root-aware format
[11:18] <Peng> Ideally, LP would be less dumb. I'm not sure whether it's supposed to be, too.
[11:18] <Peng> Yeah, the only issue you've got converting between rich-root-pack and 2a is stacking.
[11:18] <masklinn> Peng: ideally^2, lp would start by offering the same "clone" button github and bitbucket do
[11:18] <fullermd> Also, a pony.
[11:18] <masklinn> and then I'd know beforehand that Stuff Works
[11:18] <Peng> Well, and that pushing 2a up to LP is rude if not everyone using the project has a new enough version of bzr...
[11:19] <masklinn> yeah, i like ponies
[11:19] <masklinn> Peng: yep, though I think the stacked thing is creating enough pain right now that the "deciders" are looking at just migrating everything to 2a and telling users to install 2.x ppas
[11:20] <vila> masklinn: can you pastebin the relevant portion of .bzr.log leading to the traceback about bzr: ERROR: bzrlib.errors.NoSuchRevision: BzrBranch6('file:///Users/masklinn/projects/tiny/addons/stable-security-fix-2575/') has no revision xmo@tinyerp.com-20100205202639-4l5e0z4gwyvof1b2
[11:21] <vila> masklinn: migrating everything to 2a and telling users to install 2.x ppas is a good idea, you'll get smaller repos, faster bzr and the ability to bzr push stacked branches on LP, which in turn will allow you to push roughly size(changes) for new branches
[11:22] <masklinn> vila: yeah, but that requires users to install ppas on "older" ubuntus (and get lost if they're using non-ubuntu distros which don't ship 2.x, I guess) which isn't very nice to them
[11:23] <vila> masklinn: bzr-2.0 is being backported to older Ubuntu releases, this should happen RSN (tm)
[11:24] <fullermd> Just in time for 2.1 to be out, maybe  ;p
[11:24] <masklinn> villa: This should be the part of the log leading to the error: http://pastebin.com/m2e6f66be
[11:24] <masklinn> fullermd: talking about 2.1, does it change the repo format *again*?
[11:26] <jelmer> masklinn: only major versions (1.0, 2.0) change the default format
[11:26] <vila> masklinn: right, so it looks like your working tree is pointing to a revision that doesn't exist in the associated repo ? How weird
[11:26] <masklinn> vila: well that would be the uncommitted revision wouldn't it?
[11:26] <fullermd> uncommit doesn't remove the rev from the repo.
[11:26] <vila> masklinn: but it should still be in the repo
[11:27] <masklinn> oh
[11:27] <vila> masklinn: did you try something like 'bzr uncommit -r<unkown_revision>' ?
[11:27] <masklinn> nope
[11:27] <masklinn> just a plain "bzr uncommit"
[11:27] <vila> masklinn: did you try something like 'bzr uncommit -r<some_revision>' ?
[11:27] <vila> wow
[11:28] <masklinn> I'd done a bzr clone -r{something} before because I didn't want the top 2 revisions of the other repository (since I wanted to fix 2575)
[11:28] <masklinn> but uncommit was options-less
[11:30] <j^> vila: that was with 2.0.4 will try 2.1
[11:31] <vila> j^: make sure the extensions are compiled if you're running from source
[11:37] <vila> masklinn: and you had a valid working tree after your 'bzr branch' ?
[11:37] <masklinn> vila: I think so, but I can try brancing to some other repo and doing an info -v just in case
[11:38] <vila> masklinn: filing a bug with a reproducible scenario will be ideal
[11:39] <masklinn> well yeah but I doubt "reproducible 90% of the time on my own machine, never on others" would be reproducible enough ;)
[11:40] <vila> masklinn: that'd be a start towards making it 100% reproducible :) Then we'll can fix it !
[11:43] <masklinn> ok tried re-cloning the original branch (with the same parameters) to a new one, bzr info -v comes back with a clean bill of health, so it does quite seem like uncommit broke the thing. I'll try clearing my log and re-running the interesting commands
[11:45] <masklinn> and this time it worked... oh well (weird though, I get a warning about gtk, why is gtk involved in uncommit?)
[11:48] <fullermd> bzr-gtk hooks into it if it's installed.
[11:49] <masklinn> fullermd: ok, I'll kill bzr-gtk, the issues might come from that (macports's gtk seems to do nothing but crash on my machine, uncommit's issues might come from there, or the issues might be related)
[11:49] <masklinn> with a bit of luck, it'll unscrew uncommit
[11:57] <krisives> does anyone know how to use bzr-git ?
[11:57] <krisives> i cant find any kind of documentation
[11:58] <Kamping_Kaiser> bzr help git work?
[11:59] <manuee> hi everyone
[12:00] <manuee> drupal is considering moving (finaly) out of cvs, and pondering other vcs ... it'd b e nice if some of you could chip in http://groups.drupal.org/node/48818
[12:00] <manuee> i personaly would like us to use bzr, but not knowledgaeble enough to make a statement or to defend it against other options
[12:07] <krisives> `bzr help git` only gives me:
[12:07] <krisives> "A GIT branch and repository format implementation for bzr."
[12:08] <krisives> manuee: Good luck, I've noticed a lot of projects blindly hate bzr
[12:09] <krisives> http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html is a good start, and the ultimate argument is simplicity, low barrier of entry, which they should obviously appreciate if they are switching from CVS
[12:12] <manuee> thanks krisives
[12:12] <krisives> and for a shameless plug: http://santiance.com/2010/01/how-to-synchronize-code-with-bazaar/
[13:17] <masklinn> Should documentary lacks of bzr (and extensions) be reported as bugs? Because it isn't exactly clear from its help topics that, in bzr rebase, `-r` can pretty much turn it into a transplant
[13:18] <masklinn> even though it seems to work ok
[13:26] <gerard_> masklinn: I'd say it's a bug
[13:35] <masklinn> ok, so I should open a bug on bzr-rebase on their lp page?
[14:25] <bialix> it seems today is holiday, so quiet here
[14:30] <rubbs> today is a holiday?
[14:30] <rubbs> hello bialix btw.
[14:30] <bialix> hello rubbs
[14:31] <bialix> maybe it was my imagination
[14:31] <bialix> so quiet here usually on weekends and holidays
[14:31] <rubbs> There is a lot of snow in the US. I don't know if that's part of it. Large parts of the East Coast here are without power.
[14:31] <rubbs> true
[14:39] <bialix> oh, that's not good
[14:39] <rubbs> yeah. I had to spend 45 minutes digging out my car this morning.
[14:40] <rubbs> made it to work though
[14:40] <bialix> hi jam, how's you dealing with snow?
[14:41] <jam> morning bialix, not really snowing here
[14:41] <bialix> rubbs: we have similar problems here
[14:41] <jam> I guess to the east and west of me is far worse than here
[14:41] <bialix> jam: morning, can you refresh my memory about 2.1 final date?
[14:41] <jam> this week
[14:41] <bialix> that's good
[14:41] <rubbs> jam you in Midwest?
[14:42] <jam> rubbs: yeah, just south of Chicago
[14:42] <rubbs> ah. cool. I have friends who live in Elgin (sp?). I was born in Paletine and lived in Aurora for a while
[14:48] <gerard_> jam: morning
[14:51] <bialix> jam: who is release manager for 2.1 final? poolie?
[14:51]  * bialix looking for summary of new changes in 2.1
[14:54] <bialix> rats, news entries for 2.0.x and 2.1.0by releases mixed
[14:54] <jam> bialix: I think I'm still the official 2.1 releaser
[14:54] <bialix> may I beg you to write soem summary on changes re 2.0?
[14:54] <bialix> *some
[14:55] <bialix> this will be first really big release
[14:55] <bialix> 6 months of work
[14:55] <jam> bialix: http://bazaarvcs.wordpress.com/2010/01/18/bazaar-2-1-2/
[14:57] <bialix> jam: thanks
[14:58]  * bialix hopes to see nested trees landed in 2.2
[15:00] <bialix> jam: fyi about qbzr 0.18.1: the tag for this release available in both lp:qbzr/0.18 and trunk. but I suspect you'd like to use lp:qbzr/0.18 for 2.1.x anyway
[15:00] <ronny> btw, what exactly is nested trees?
[15:00] <jam> bialix: well, it wasn't there when I tried doing the packaging earlier, but it doesn't really matter. As long as your tags can be found, I'll get them
[15:01] <bialix> ok
[15:07] <bialix> ronny: svn:externals, git submodules, hg subrepos
[15:11] <ronny> i see
[15:44] <mathrick> hi, what's the best / easiest way to install a post-commit hook in a single repo?
[15:45] <mathrick> I'd be happy to be able just to call a shell command, really, scp is all I need
[15:46] <rubbs> are you looking for just a mirroring system?
[15:47] <rubbs> if so, http://wiki.bazaar.canonical.com/BzrPlugins, under "Publishing" might be what your looking for. There are a few options there.
[15:47] <mathrick> right, but I need a single file, more or less
[15:48] <mathrick> the ones I've seen want to push the whole tree I believe
[15:48] <rubbs> ah, ok.
[15:49] <mathrick> so I guess what I need is to read some kind of config on the branch, but how'd I go about it?
[15:50] <mathrick> hmm
[15:50] <rubbs> not sure.
[15:50]  * mathrick reads automirror's source
[15:50] <rubbs> sorry I couldn't be more help :(
[15:50] <mathrick> nah, it's fine
[15:51] <bindjp> hi, was trying to get the bzr explorer to work in snow leopard and with no luck.  The installer looks like it doesn't install it
[15:52] <mathrick> bindjp: did you read the note on http://wiki.bazaar.canonical.com/MacOSXDownloads ?
[15:52] <mathrick> "he "Desktop" bundles include Bazaar Explorer and QBzr in addition to the contents of the "Core" bundles. It requires that you have the Qt framework installed. For Mac OS X 10.6 Snow Leopard, you must install the 64-bit Qt 4.6.1 framework."
[15:53] <bindjp> mathrick: yeah, I installed that
[15:53] <bindjp> mathrick: maybe there is a way to clean out the previous installs and start again?
[15:55] <mathrick> dunno really
[15:56] <bindjp> mathrick: I will see what I can find, thanks, just wondered if anybody ran into troubles too
[15:57] <mathrick> bindjp: yeah, I was making sure you didn't run into the most obvious issue. I don't really know anything past that, sorry
[16:16] <doctormo> I'm getting an odd error when I try and checkout lp:drawberry
[16:16] <doctormo> ErrorFromSmartServer: Error received from smart server: ('error', "'Inter1and2Helper' object has no attribute 'source_repo'")
[16:19] <james_w> bug 513432
[17:05] <mathrick> hmm, how do I get the pathname under which a WorkingTree lives?
[17:06] <vila> wt.basedir
[17:19] <bialix> rats, unicode error in unshelve --preview
[17:19] <bialix> rats rats rats
[17:22] <mathrick> vila: thanks
[18:01] <verterok> jelmer: hi! fwiw, I just tagged bzr-xmloutput 0.8.6 ;)
[18:27] <ahasenack> hey guys, bzr is throwing at me an internal error when trying to checkout a repository
[18:27] <ahasenack> http://ubuntu.pastebin.com/d717de539
[18:29] <rubbs> bug 513432
[18:29] <ahasenack> is this known? Should I go ahead and file a bug report?
[18:29] <ahasenack> ok
[18:30] <rubbs> looks like they're working on it
[18:30] <ahasenack> rubbs: thanks
[18:30] <rubbs> np
[18:32] <lamalex> is anyone here familiar with trac-bzr?
[18:39] <jelmer> verterok, hey
[18:39] <jelmer> verterok, awesome, I'll make sure it ends up in Debian/Ubuntu
[18:39] <verterok> jelmer: cool, thanks! :)
[18:52] <lamalex> I can't get it to display different branches
[19:34] <exs> hi guys. i have a question. i have a inited branche on locale space and want to upload the content to my webspace too. how i have to do this. the documentation irriteded my a little bit.
[19:37] <exs> the best way were. i devel on my local space. and then i have a upload command and after that bzr uploads the whole develcode at my webspace.
[19:38] <exs> and it would be greate if i could edit some commands executing before content will uploaded
[19:38] <rubbs> so, just to clarify, you want to be able to push just the working directory to a location? or do you want the whole history to go with it?
[19:39] <exs> only the actual revision
[19:39] <exs> no history needed
[19:40] <rubbs> ok, why would you ahve to use bzr? or do you want it do to that while commiting? I guess I'm asking why you couldn't just ftp or sftp or scp the directory to the webspace and not use bzr at all?
[19:40] <exs> because i used a wiki where other persons can change the code
[19:40] <rubbs> *not use bzr to upload at all* is what I ment
[19:41] <rubbs> so you want the web space to be versioned as well? so when another person changes it you can get that version?
[19:41] <exs> in additions its more comfortable when you are able to upload the whole content to the webspace while commiting
[19:41] <rubbs> I'm not quite understanding the set up.
[19:41] <exs> exectly
[19:42] <rubbs> just curious, doesn't the wiki have a version control built in?
[19:42] <exs> thats right, but its too hard to go hand by hand and look which files were edtied
[19:42] <rubbs> ah, ok.
[19:43] <exs> the wikipages are txtfiles. and this txtfiles i want to edit on my local space.
[19:44] <rubbs> well, there is a problem if someone changes it on the web by hand, you would have to modify the wiki to commit every change to bzr on the webserver.
[19:44] <exs> i thought bzr registrate every change automatically
[19:46] <exs> the wikisoftware is dokuwiki. it edit only textfiles saved on my webspace. other user can edit the wikipages too, so i need bzr to synchronize my local code with the code may edited by other users
[19:47] <rubbs> so how do you get the code from the webspace, do you just copy it over?
[19:47] <exs> yea
[19:47] <exs> i login with ftp
[19:47] <exs> then go to the dir where my files are saved and then copy to my local space
[19:48] <exs> can you german maybe?
[19:49] <rubbs> exs: sorry my german is REALLY bad. I wouldn't be able to understand you. It isn't your english that is the problem with me asking all the questions. It's just me needing to know how you work, so I can help you figure out how to make bzr work for you ;).
[19:51] <rubbs> bzr will understand what has changed automatically between the history you have and the working tree (your revision you work on) that's why you can use diff and the like
[19:52] <rubbs> but it will not automatically know if the directory on your webspace has changed.
[19:52] <exs> rubbs: the point is this. i have a bzr branch already where i code my programs. i want to publish the code on my webspace in a certain direcotry where wikiuser can edit the files. after certain time i want to syncronize both branches. maybe the user edited something new, and i added something new in the code and i want others to see it. the files i work on them are simply txtfiles. and dokuwiki just edit simply txtfiles. the whole wiki consists of txtfile
[19:53] <rubbs> Ok, got it. I think I can help, but I have to use the toilet.... I'll be right back.
[19:54] <exs> rubbs: ah now i understand what you mean :) yea that could make a problem. but my idea was that if something has changed so there are difference that bzr will show me this in the next commit and i solve the problem by hand or something like that
[19:54] <rubbs> exs: I think I still have an idea that will work, but I'll be right back.
[19:54] <exs> ok
[19:58] <rubbs> ok, back. Here's my idea:
[20:01] <rubbs> you could create a local branch and create a remote branch on your webspace. When changes happen on the wiki, the remote repo will keep track of them. then to get them to your local branch, you could run "bzr merge --uncommitted ftp://webspace/dir" That will pull all the changes on the webspace. Then you make your changes locally, then do a "bzr push --overwrite" That will put all the changes on your local to the remote.
[20:02] <rubbs> then you can use a plugin like "push and update" to make the working tree become updated.
[20:03] <rubbs> http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
[20:04] <jelmer> verterok, hi
[20:04] <verterok> jelmer: hey
[20:04] <rubbs> exs: http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html#merge
[20:04] <jelmer> verterok, any chance you can upload a tarball as well?
[20:05] <rubbs> exs: hopefully that helps a little
[20:05] <verterok> jelmer: already uploaded :)
[20:05] <jelmer> verterok: oops
[20:05] <jelmer> verterok: ignore me then :-)
[20:05] <exs> why --uncomitted and --overwrite?
[20:05] <verterok> jelmer: but it's a 'bzr export' instead of a 'setup.py sdist'
[20:07] <rubbs> exs: when the wiki user makes a change, that will not be a part of the history yet (because it was never committed) so when you merge in the "uncommitted" changes, you are pulling all the changes on the webspace.
[20:07] <rubbs> exs: the more I think about it the more the --overwrite might not be necessary.
[20:10] <jelmer> verterok, uploaded
[20:10] <jelmer> verterok, thanks!
[20:10] <verterok> jelmer: awesome, thanks!
[20:56] <exs> rubbs: ok thx for help, but i could not try it now but i will try it later. can u answer me another question. what is the sense of repo-init? what exectly do this command?
[20:58] <rubbs> exs: init just makes one stand alone branch all that history is stored in that branch. init-repo will create a "shared" space for many branches. This allows you to save disk space when you have multiple branches with similar code. If you are only going to be using 1-2 branches at a time, it isn't that important.
[22:19] <lifeless> Is there a 'rhett trapmann' here?
[22:20] <jpds> lifeless: He's gone, long gone.
[22:21] <poolie> hello
[22:21] <lifeless> jpds: was he here at all?
[22:21] <lifeless> the account has been blacklisted (yay)
[22:21] <lifeless> hi poolie
[22:21] <jpds> lifeless: No, he just got banned from LP.
[22:21] <lifeless> but it was his second account anyway...
[22:21] <lifeless> so I expect a third pass until someone actually manages to sit down and explain things.
[22:24] <RAOF> I'm having trouble branching lp:launchpad-integration; bzr fails with bzrlib.errors.ErrorFromSmartServer.
[22:25] <RAOF> Full error is http://pastebin.ca/1790660 and http://pastebin.com/f1c08c1df
[22:36] <mwhudson> RAOF: are you branching from an old format branch into a 2a repo?
[22:36] <mwhudson> it's a server side bug though, must chase the SAs about getting that deployed
[22:36] <RAOF> Possibly.
[22:37] <RAOF> lp:launchpad-integration has Branch format: Packs 5, and I am branching into a 2a repo.
[22:37] <mwhudson> yeah
[22:38] <mwhudson> branch standalone first or something
[22:39] <RAOF> Or, it turns out, branch over http first.
[22:39] <RAOF> That worked.
[23:41] <exs> can someone say how to change the message in a commit?
[23:42] <bob2> you can't
[23:42] <LeoNerd> You can't. The revision is signed by a checksum.. that checksum is the identity of the revision. If you change the message, you change its identity, and have now broken it.
[23:42] <bob2> you can uncommit and recommit with a new message, if you like
[23:42] <LeoNerd> Well, not broken.. it's just now different
[23:42] <bob2> but that'll confuse anyone who has pulled from you