/srv/irclogs.ubuntu.com/2010/02/27/#bzr.txt

jonohi all01:22
jonois there a Python bazaar module that I can use to check out code?01:22
Pengjono: import bzrlib. Aside from some build code and about 20 lines in the "bzr" executable, that's the entirety of bzr.01:24
jonoPeng so I can use it to check out code?01:26
Pengjono: I don't know what exactly you mean by "check out code", but probably.01:27
jonoPeng bzr branch lp:foo01:28
jonopeng are there docs anywhere for it01:29
jono?01:29
jonoahaha found them01:29
Pengjono: That should be easy enough to do, but I honestly do not know how. You could check out bzrlib/builtins.py:cmd_branch to see how "bzr branch" does it, or maybe the docs give an example.01:30
jonook cool01:30
jonoI want to add an example to Acire :)01:30
Pengsubprocess.call(['bzr', 'branch', 'lp:foo']) is cheating, right? ;D01:31
Peng(Sorry, I shouldn't encourage that.)01:31
jonohaha01:32
jonothat *is* cheating01:32
jono:)01:32
jonoPeng any idea what the full qualified path of a branch on LP is?01:37
jonoremote_branch = Branch.open("lp:python-snippets")01:37
jonodoes not work01:37
PengYour code should ask the directory service, which I also do not know how to do.01:39
Pengs/should/might have to/01:43
jonocan anyone else help me figure this out?01:43
jonothanks Peng01:43
* Peng inserts several *shrug*s01:43
jonolol01:43
jonolifeless, surely you must know :)01:44
jonoyou are an expect among these parts :)01:44
PengHe's gone. :<01:53
chromakodehey #bzr, can I revert/remove a specific commit from the history?04:36
chromakode(a bad merge)04:37
PengYou can revert the changes it made -- "bzr merge . -r 50..49" or so -- but you can't remove the revision from history.04:38
PengWell, if it's the most recent revision, you can use "bzr revert -r -2", or even "bzr uncommit" to remove it from history. (But the latter would be a pain for users if you've already pushed it.)04:39
chromakodeyeah -- it's already got commits on top of it04:39
chromakode:(04:39
chromakodebest is to revert. I didn't know you could do a range backwards!04:39
chromakodePeng: what exactly are the revnos I should pick for that example?04:41
chromakodeI want to get rid of revno 88, retaining 89 and 9004:41
Pengchromakode: Should be 88..87, but try it and see.04:42
PengYou can always "bzr revert" if it goes horribly wrong.04:42
chromakodeneato!04:43
fullermdEr, "revert -r-2" wouldn't remove anything from history...04:44
chromakodehe was saying uncommit would remove it from the history04:45
chromakodeI suppose you'd commit back the following 2 commits04:45
chromakodethis looks good. thanks.04:45
PengYeah, that was worded a bit badly.04:46
chromakodePeng: so, if the revnos are in reversed order, it treats the diff in reverse?04:47
chromakodethat's really cool04:47
PengRight. :D04:50
chromakodehmm. it's giving me a lot of conflicts.04:50
chromakodeis there any way to tell it "use the merge-tree version!"?04:51
Peng"bzr resolve" can do it, at least if you're using a very recent version of bzr.dev.04:52
chromakodechecked there :(04:53
PengUm, it shouldn't conflict too badly, unless, well, a lot of conflicting changes have been made since.04:53
chromakodeurgh.04:54
chromakodeyes. they have. to every header file04:55
* chromakode slaps his teammates04:55
wgrantIf I'm using a lightweight checkout with a treeless repository, is there some way to store uncommitted changes before I switch, like switch-pipe does? Should I just shelve?09:49
fullermdshelve should work.  Whether unshelve will work well...09:49
fullermdI'd guess it probably should, at least as well as e.g. an update across that pair of revs with local changes.09:50
wgrantHm, so the shelf is stored in the checkout. I seeeeee.09:53
* wgrant checks how pipeline does it.09:53
fullermdYeah, shelf is WT-local.09:53
wgrantAh, it uses shelf but directs it to the branch. Hmm.09:54
lifelesswgrant: bzr shelve; bzr switch; bzr unshelve - will work fine.10:12
lifelesswgrant: as the checkout is constant in the environment you described10:12
wgrantlifeless: Right, but is there a way to store uncommitted changes in the branch?10:14
lifelessno10:15
lifelesscommit them to a new branch10:16
lifelessor to a tag10:16
lifelessor something10:16
lifelesswhy though?10:16
wgrantI thought I'd try lightweight checkouts, since Launchpad trees are huge and slow, and it seems to work well with pipeline.10:19
lifelesssure10:23
lifelessthat doesn't answer the question10:23
lifelesswhy do you need to stash the change, not commit it, and tie it to the branch10:24
wgrantlifeless: I might have realised half-way through a change that it needs a change in a some other branch.10:29
wgrantAlthough I guess that's more covered by the pipeline case.10:29
lifelesswgrant: sure; shelve; switch; make change; commit; switch back; merge; commit; unshelve.10:29
wgrantlifeless: I guess. It's just a bit different from the great workflow that pipeline gives.10:30
lifelesswgrant: sure; you're working with the primitives.10:30
lifelesswgrant: what I *don't* get is how that is different10:30
lifelessas in, I don't see where the changes are stashed affecting your use case10:31
wgrantI sort of like attaching the changes to their branch.10:32
wgrantMakes it easy to keep track of them.10:32
wgrantIf they're attached to the branch I can be lazy and shelve without a message.10:32
fullermdYou can always commit them and uncommit them later.  Unless you forget, of course.10:33
wgrantTrue.10:33
lifelesswgrant: changes to the core to make it better sought after10:34
lifelesspersonally, in my pending dir I shelve everything to one space, no comments, and I don't get more or less confused10:35
lifelesswgrant: we could though, when shelving default to attaching the nick as a comment10:35
lifelesswhat do you think?10:35
wgrantlifeless: That might be handy.10:35
lifelessfile a bug10:36
wgrantAlso, last time I tried this shelve didn't let me get a diff. It might be more usable now that it does.10:36
wgrantIs there a repo: or similar branch alias?10:51
lifelesswhat would that mean10:51
j^hi, is there an example somewhere of how to use post_change_branch_tip10:51
lifelesssure, theres a few plugins around now that use it10:52
wgrantlifeless: It would be an alias for the repo of the current branch, so I could say bzr switch repo:somebranch10:52
lifelesswgrant: just say 'bzr switch somebranch'10:52
lifelesswgrant: it will dtrt10:52
j^i.e. http://doc.bazaar.canonical.com/latest/en/admin-guide/hooks-plugins.html?highlight=post_change_branch_tip10:52
wgrantlifeless: ...oh. That is nice.10:52
j^links to http://doc.bazaar-vcs.org/en/plugin-guide10:53
j^which gives 40410:53
lifelessj^: hmm, not sure about that10:54
lifelessanyhow10:54
spivj^: http://doc.bazaar.canonical.com/plugins/en/ works10:56
j^still confused about how post_change_branch_tip works10:57
lifelesshttp://github.com/djmitche/buildbot/blob/06ce8e7e79b2ffa1a301ac45c7155899d6a0e6da/contrib/bzr_buildbot.py has an example of it10:58
spivj^: the bzr-email plugin has an example of using it, see http://bazaar.launchpad.net/~bzr/bzr-email/trunk/annotate/head%3A/__init__.py#L10610:58
lifelessj^: but what are you confused about in particulalr10:58
lifelessspiv: google for the hook name, its interesting on the 2nd and later pagers10:58
j^i have a server where several people push changes to, i want to run a command on the server each time someone pushes new versions, post_change_branch_tip seamed to be the right hook, can not make out how to enable it on the server though11:00
lifelessj^: install it on the server11:00
lifelesse.g. if you have a setup.py, run setup.py so as to install it into bzrlib/plugins/ wherever that is in your python path11:00
spivj^: as lifeless says, install the plugin with the hook on the server (and install it system-wide, so that it will be loaded by any user that runs 'bzr'), and make sure people push using the smart server (e.g. bzr+ssh, not sftp).11:03
* spiv wanders off11:03
lifelesshmm11:16
lifelessI was sure I had writted a diff hook11:16
lifelessspiv: I would love news_merge to use ReST parser11:28
lifelessspiv: my other NEWS files use alternative section markers11:28
=== j^ is now known as bot0x
=== bot0x is now known as j^
=== salgado is now known as salgado-afk
lifelessspiv: lp:bzr-commitfromnews12:40
jelmer__was the darcs 2.4 release announcement just cross-posted to the bazaar and git lists?12:40
=== jelmer__ is now known as jelmer
jelmermoin lifeless, spiv12:41
jelmerlifeless: Happy birthday!12:41
lifelessjelmer: thanks ;)12:41
jelmerlifeless, will commitfromnews also use --fixes ?12:44
fullermdjelmer: It wasn't cross-posted.  The mails were just re-arranged after it was sent, allowing it to appear on any list that's convenient   :p12:44
=== radoe_ is now known as radoe
=== radoe_ is now known as radoe
lifelessand moin20:13
lifelessjelmer: hi21:03
jelmerlifeless: hello21:03
lifelessjelmer: I'd like it to do --fixes automatically, haven't looked at what is needed yet.21:03
lifelessjelmer: I filed a bug when I registered the project saying this; if you wanted to fixit :)21:04
jelmerlifeless: Ah, sorry21:04
jelmerlifeless: it works well, btw21:04
jelmerthanks for publishing it21:05
lifelessmy pleasure21:05
lifelessI'm trying to be a bit rougher on development friction21:06
jelmerwhat do you mean with development friction?21:08
jelmerI haven't heard friction being used in this context, only as something that exists between people.21:10
lifelessI mean between me and machine21:13
lifelessand me and tools21:13
lifelesshttp://en.wikipedia.org/wiki/Friction21:13
lifelesseffort put into writing code = F21:14
lifelessthings that sap that effort and make it get less work done = Ff21:14
lifelessI *think* the concept of interpersonal friction comes from the analogy between anger and heat21:15
lifelessas the energy friction bleeds off is heat21:16
jelmerlifeless: Ah, thanks.21:18
lifelessjelmer: if you'd like to add fixes support that would be awesome21:23
jelmerlifeless: I might have a look at that when I have a moment to spare.21:23
lifeless:P21:24
lifelessI'll probably look at it when I need to use a fixes clause21:24
lifelessI just haven't so far21:24
jelmerhaving --fixes might actually save me quite some time21:24
maxbI have a svn repository, with lots of legacy branches that are merged to trunk, but there's no metadata to say so. (Before svnmerge, or 1.5 merge tracking, and not svk). Is manually mangling in some bzr-svn bzr:merge revprops a neat trick or a terrible shoot-self-in-foot idea?21:25
jelmerI usually forget to specify --fixes, then I uncommit, look up the bug number in NEWS and recommit with --fixes21:25
lifelessjelmer: so, when I forget I ignore it ;P21:25
lifelessjelmer: but you might want to just fix the process next time - to make time on the basis that you'll save time :>21:25
jelmerheh21:25
jelmermaxb: It's a good way to shoot yourself in the foot..21:26
maxbhmm. It seemed so tempting21:26
maxbAnything in particular I'm liable to break?21:26
jelmermaxb: if you're sure there are no branches out there that were created from that svn repo using bzr-svn you could attempt it21:26
maxbI can ensure that21:27
lifelessmaxb: the revids from bzr-svn are deterministic21:27
maxbwhich is indeed a great thing about it21:27
lifelessmaxb: so if anyone else, ever, runs bzr-svn, they wouldn't be able to merge with you21:27
maxbPresumably, yes, they will, if I've munged the svn repo before anyone ever bzr-svn's it21:28
lifelessmaxb: or perhaps it is 'if anyone else ever has, ...'21:28
lifelessright21:28
maxbIt's a company repository, and freshly cvs2svn-ed, so I can state confidently that there are no prior bzr-svn-ifications in the wild21:31
jelmermaxb: ah, should indeed be possible in that case.21:32
maxbUnfortunately I couldn't sell a direct cvs2bzr to the powers that be :-)21:33
jelmermaxb: please note that bzr-svn doesn't interpret svn:merge21:33
maxboh. that's unfortunate. I may have to have a go at hacking on that, then21:33
maxbPresumably there's no reason why it couldn't, just no one's written the code?21:34
maxbOh, except I'd be glibly ignoring subtree mergeinfo21:35
jelmermaxb: There is a reason, bzr doesn't support tracking cherrypicks21:36
jelmermaxb: So you have to do analysis of the svn:mergeinfo data to see if *all* revisions for a particular path are merged before you can add the last revision in svn:mergeinfo for that path as a parent21:37
maxbtricky, but doable21:38
jelmermaxb: Expensive, performance-wise.21:38
jelmerIt also requires a mapping format change.21:38
jelmerpersonally I'd rather see somebody investigate the possibility of tracking cherrypicks, even if we don't start doing smart things with that data yet.21:39
maxbEven if you did track cherrypicks, you'd still want to resolve them into full-ancestry merges when that was the actual case21:41
jelmeryes, but that logic would be in bazaar, not bzr-svn21:41
maxbtrue21:41
jelmer(.. and bzr-hg and bzr-git)21:42
maxbhg and git track cherrypicks ?21:42
jelmergit does at least, on a revision level21:43
maxbwhoa, I completely missed that21:43
jelmerit does it (at least optionally) by simply putting the sha of the cherrypicked commit in the newly created commit21:43
jelmerI'm not sure if it actually uses it do improve merge quality21:44
lifelessAFAIK it doesn't21:44
maxbI think my next step is to spend some more time poring over bzr-svn's guts21:46
lifelessI wish lp mailed me back saying 'your bug might be a dup, look at XYZ'21:55
* lifeless files bugs21:55
jelmerlifeless: Yes, me too.21:58
jelmermaxb: tbh, I don't think that sort of analysis would belong in the default bzr-svn mapping.21:59
jelmermaxb: I don't want to discourage you, but I think I should mention that upfront.22:00
maxbjelmer: It's a fair comment. It might be desirable only for people using bzr-svn for a onetime migration away from svn22:04
jelmermaxb: it's also only a temporary solution, since it we would need another mapping change (and an upgrade path) when proper cherrypicking support in bzrlib would be added22:05
maxbThe mapping issue is a hard one, but I'm already contemplating using a custom-hacked bzr-svn to migrate some slightly screwy history out of svn anyway22:12
maxb(The problem there is tags which don't show up in bzr because they were made from a mixed-revision working copy, so bzr-svn treats them as branches)22:13
maxbI guess I'll need to make sure I also change the revision-id generation so that they are different to what an unhacked bzr-svn expects22:16
lifelessjelmer: bug 529227 bug 52922622:17
ubottuLaunchpad bug 529227 in launchpad "wishlist: show candidate dups on all bugs / provide a way to scan for duplicates of a bug" [Undecided,New] https://launchpad.net/bugs/52922722:17
ubottuLaunchpad bug 529226 in launchpad "wishlist: tell me about dupes when I file-by-email" [Undecided,New] https://launchpad.net/bugs/52922622:17
jelmermaxb: You can just create a new mapping format22:18
jelmermaxb: That should change the revid as well22:18
jelmermaxb: actually, you should be able to just use a vanilla bzr-svn plugin and provide your own plugin that registers a new mapping format that does what you need.22:18
maxbinteresting. It's clear that I need to spend some more time learning about the internals :-)22:19
Demosthenescan someone tell me what this python error means? bazaar quit working today at noon and returns this on every invocation. http://pastebin.com/wpgG4hsX22:22
beunoDemosthenes, I have no idea what that error is, but you are using a very old version of bzr22:24
Demostheneslenny standard22:24
maxbDemosthenes: I'm guessing it means that a .pyc file has been corrupted22:29
Demosthenesi'm checking files now22:30
maxbI'd start wondering about the health of your hard disk :-(22:30
maxbI'd also strongly recommend upgrading bzr if you use it regularly. Debian stable is far too stable for an active project like Bazaar22:31
jelmerlifeless: Thanks, subscribing22:32
PengPresumably /usr/lib/python2.5/socket.pyc22:32
Demosthenesmaxb: i'm seriously concerned myself, as i haven't made changes in a bit...22:32
Demosthenesi'm running a compare against my last backup for /usr22:32
Demostheneseww i'm having some files i'd never change not match...22:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!