/srv/irclogs.ubuntu.com/2008/04/22/#bzr.txt

gamblerhi00:38
gamblerwhy doesnt the fedora bazaar version commands match the ones in the webpage documentation00:38
gamblerah i c diff pkg00:39
gamblerthats really confusing00:40
pooliegambler: you want bzr not baz00:41
=== mw is now known as mw|out
Necorohey - if I've a working tree ... and want to checkout the tree from to revisions before - how do I do this?00:56
Necoros/to/two/00:56
Necoroand I want to do this _in place_00:56
beunoNecoro, just specify the revision with -r00:59
beunoI suspect -r -2 might work00:59
Necorobut using which command?00:59
Necoroco does not work - as there is already a checkout in place00:59
Necoromerge ... does strange things01:00
beunoNecoro, I don't follow then01:00
beunoyou already have a checkout01:00
beunoand you want to go back 2 revisions?01:00
Necoroyes01:00
beunooh01:00
beunobzr revert -r X01:00
Necorothat's easy -.-01:01
beunolike most things with bzr  :)01:01
Necorothanks :)01:01
Necoroah ... some things are just not possible ;)01:01
beunoNecoro, file bugs about it and give it time...  we've got amazing developers  :)01:02
NecoroI can think of trying to merge two branches that bzr thought don't have a common ancestor ;)01:02
Necoroyeah :) ... I tend to just ignore this issues ;)01:02
* Necoro adds #bzr to the list of standard channels01:03
beunoNecoro, welcome  :)01:04
Necoro*g*01:04
beunojelmer, btw, If there's anything I can help you with the bzr-gtk release, let me know  :)  I'm eager to see a new version out there01:06
fullermdHm.  I merge unrelated branches with some regularity   :p01:14
Necorofullermd: how?01:17
* fullermd shrugs01:17
fullermdmerge -r0..-101:17
Necorohmmk01:17
* Necoro adds this to the list of interesting bzr commands01:17
fullermdNot what you want if you INTEND them to be considered related, of course.  But mine really are unrelated.01:18
Necorooh01:18
NecoroI indeed want to have them considered related ...01:18
fullermdTo do that requires the ability to alias file and revision id's.  Lot tricksier.01:19
fullermd(both on the code side, and UI-wise doing it I expect)01:19
Necorofullermd: oh ... than it's not worth it ;)01:20
fullermdOh, most things are worth it.  Someday(tm).01:29
Necorohehe ... but not to have ~2-3 files merged ;P01:30
ubotuNew bug: #220464 in bzr "Bazaar doesn't detect its own stale locks" [Undecided,New] https://launchpad.net/bugs/22046403:26
bob2is there any way to get data from rich-root-pack branches into pack-0.92?  even bundle doesn't work.03:26
jameshbob2: no03:29
jameshbob2: abentley says he's working on one format to rule them all though03:29
fullermdTheoretically, a rich root format (not -pack, but its successor) will be The Format at some coming point.03:30
jameshfullermd: I think that's what abentley's pack-1.4 (or maybe pack-1.5 now) format is going to be03:33
abentleybob2: rich-root-pack wouldn't exist if pack-0.92 could represent all its data.05:50
bob2oh, I know, but since I don't care about the root richness, I was hoping I could throw some info away and get it into pack-0.92 :)05:52
jameshbob2: throwing info away would give you different revisions05:56
emgenthello people06:00
=== keithy_ is now known as keithy
pooliehello emgent06:35
poolielifeless/spiv: what would you say to a source test that forbids the use of the assert statement?07:15
spivpoolie: I have mixed feelings about that07:19
spivBecause I think that the assert statement is a sane thing to use sometimes.  But it's very easy to misuse, so perhaps disallowing it entirely is the best policy.07:20
spivSo I'm +0.5 on it, I guess.07:21
pooliespiv: what kind of thing?07:22
pooliei mean07:22
pooliecan you give me a good case for committing it in mainline code?07:22
spivFor a purely internal-to-bzrlib API, an assert that e.g. "type(revision_id) is str" could be reasonable.  The sort of thing that would catch misuse of an API within bzrlib.07:23
pooliein C i'd certainly do that07:24
pooliebut the combination of not having a clear distinction between debug and other builds07:24
pooliemeans it just doesn't seem like a good tradeoff07:25
spivThe thing that makes me lean towards banning them is plugins.07:25
poolieall you really gain is slightly shorter syntax, right?07:25
pooliemm?07:25
spivBecause it's too easy for a plugin to accidentally trip over an assert than was intended to catch a bzrlib-only mistake, and really that shouldn't be a user-visible error.07:25
spivRight, you can explicitly use "raise AssertionError, ..." instead, but it feels a bit funny to raise AssertionError.  Probably that's not a hard habit to break.07:26
spivSo I share your feeling regarding debug builds: asserts are the sort of thing that should happen for developers only, to help them know when they've misused an API or similar, to make development go faster.  They shouldn't be depended on to preserve the integrity of the system, e.g. in the face of bad user input.07:29
spivHmm, lag.07:29
spivBut of course we don't have debug builds, so I guess we never have a good time for an assert :)07:29
spivI guess I've talked myself into agreeing with you :)07:30
thumperdoes bzr work on python 2.3?07:58
thumperor does it require 2.4?07:58
jameshthumper: it uses decorators, which were introduced in 2.407:58
thumperjamesh: ta07:58
jameshdo people still use 2.3? :)07:59
pooliejamesh: rhel has something remarkably old iirc08:00
jameshah.08:01
jamesh2.4 is around 3.5 years old, so I guess it'd still be in enterprise distros08:01
poolieand i guess their users are also often (understandably) slow to upgrade08:02
pooliebut even that may be changed now08:02
PengMy shared web host has 2.4 installed, but /usr/bin/python points to 2.3.08:02
jameshpoolie: did you see my email about problems with the new bzrtools package?08:02
poolie"import parser" ftw :)08:02
jameshI remember making pygtk-2.0 depend on Python 2.2 back in 2003 as being a bit contentious08:04
jameshthat was 2 years after 2.2's release08:04
pooliejamesh: i see it now08:10
pooliejamesh: i'm on a call, could you file a bug and assign it to me marked High?08:10
pooliethanks08:10
jameshpoolie: okay.08:10
jameshpoolie: bug filed at https://bugs.edge.launchpad.net/bzrtools/+bug/220519, but I can't change its importance08:18
ubotuLaunchpad bug 220519 in bzrtools "bzrtools 1.4.0-1~bazaar1~hardy1 package installs plugin in wrong location" [Undecided,New]08:18
pooliejamesh: hm didn't someone else mention a problem like this in setup.py?08:21
jameshpoolie: the thread about getting bzr to check in extra directories might be the answer to this bug08:22
poolieit seems like the policy regarding this has changed in python?08:22
pooliei guess not08:23
jameshhaving bzrtools installed the way it is is not an inherently bad thing (other than the fact that bzr can't find it)08:23
pooliei just don't understand why we got those bugs all this week08:23
PengBlah, bzr.dev and bzr-svn 0.4.9 don't go together so well.08:23
jelmerbeuno: thanks09:23
awilkinsjelmer: Branching-schemes in bzr-svn ; is it essential to set them BEFORE pulling things?11:37
awilkinsI ask because I had pulled around 9600 revisions, then I tried pulling a branch ; the extra 100MB of revisions told me that this wasn't properly noticing that it was a branch. I've set the branching scheme and now a pull on the trunk wants to start again at r 111:38
awilkinsI used the list scheme  ; I've listed trunk, branches/*11:38
awilkins(lines, not CSV)11:38
awilkinsShould you list trunk as a branch, for starters :-)11:39
awilkinsOk, answered that one ... "Yes", or it sulks11:40
PengIt didn't auto-detect the scheme correctly?11:50
awilkinsIt's a bit of a stinky repo layout11:50
PengAnd shouldn't that be trunkN?11:50
PengRather than listing them or something?11:50
PengAh.11:50
awilkinsPeng: There is a "list" branching scheme that just takes a list of paths (or globs)11:51
PengOk.11:51
awilkinsIf you do a --set it pops EDITOR open for you to enter it11:51
PengIf it's just trunk and branches, trunkN should be good enough..11:51
awilkinsPeng: It didn't seem to be - it was adding more than 100MB of extra packs when it should have been a few extra revisions for tweaks to the files (things like changing version numbers)11:52
awilkinsIt's a large tree, so that's what I'd expect if it was just thinking "hmm, this huge folder has been copied"11:53
awilkinsThe tree layout has been messed around a bit since r0 as well, so the lack of some file features in bzr (like copy) is probably hurting too.11:54
awilkinsBut these particular cases should be quick ; and it's doesn't explain the sudden desire for it to pull all 9600 trunk revisions again11:55
awilkinsMaybe I pulled it with an old bzr-svn and the new mappings hate the old ones.11:56
* awilkins trashes it and schedules a job for it to pull again overnight11:56
awilkinsTakes about 10 hours or more to get a full trunk pull on this repo (oh for horizon history...)11:57
awilkinsHorizon history would be even cooler if it automatically worked out the ancestry on a branch you asked for and pull revisions back far enough to get it.11:58
awilkinsSo the horizon could move backwards even after it had been set at some recent revision in trunk.11:59
awilkinsMind, the svn client has been pulling just a *working copy* of this trunk for the pas 2 hours (over a LAN), so 10 hours sounds almost reasonable for a 9600 revision history right now)12:00
awilkinsNot sure if it's the shiny new full-disk encryption crapware they've foisted on us contributing to that either12:00
=== pmezard_ is now known as pmezard
=== mrevell is now known as mrevell-lunch
=== bigdo2 is now known as bigdog
=== thekorn_ is now known as thekorn
=== mrevell-lunch is now known as mrevell
black_was wondering, if you have two branches, and you want them to diverge say for something like a database connection string, but you still wanted to push and pull and merge between them, how do you mark a revision such that when people pull from you they won't get that revision?  I've tried "revert ." to try to mark things but when I start merging back and forth the branches will eventually end up the same.  Please excuse the noobness of the que14:09
black_stion :)14:09
PengYeah, I don't think you can do that.14:10
black_ahh, darn, that stinks then :)14:10
LeoNerdIsn't a DB connection string more of a config item than source code, anyway?14:10
black_well I through that out as an example14:10
black_in the past I've had two branches of a website that I had running on two different servers and certain paths had to be different based on which server they were on14:11
black_but I still wanted to keep them in sync14:11
black_s/through/threw14:12
black_I'm a long time svn user, and since you have to manage merges yourself anyway this wasn't much of a problem (other than all the hard work managing the revisions by hand)14:12
black_bzr seems like just the tool to solve the problem, but I need to be able to mark certain revisions as already merged14:13
black_without actually merging the content14:13
james_wso you tried merging and then "revert ."?14:14
LeoNerdOne idea that occurs to me is you could keep the "abstract" stuff in one branch, then pull two other branches off that for the specific changes14:14
LeoNerdWhat's really ideally needed in code I suspect would be a postwrite/preread filter hook14:14
LeoNerdSo you could filter the changes, so what bzr sees/writes is a generic version14:15
black_I start out the same, make appropriate changes on one branch, commit the changes to that branch, switch to the other branch merge the changes in but then do a "revert ." to back out the changes while still keeping a record of the change, however in practice this doesn't work because as soon as you start merging back and forth again, bzr is smart enough to be able to reconcile everything and make them the same, which in this case isn't what I w14:15
black_ant.14:15
black_I really like the idea of an abstract branch14:16
black_that might work nicely14:16
black_just make sure you always make your changes in the abstract branch14:16
LeoNerdAlso, you might consider "bzr shelve" to temporarily revert out the local changes, then commit what's "clean", then unshelve it back in again14:20
LeoNerdI often do that for doing partial commits14:20
black_thanks for the help :)14:51
Necorohmm ... just noticed that "repository/obsolete_packs" needs the most memory in my .bzr dir14:51
Necorois this cleaned automatically sometimes, is there a command to clean it - or shouldn't it be cleaned at all?14:52
PengThat's odd.14:52
PengOh, never mind, not impossible.14:52
PengYes, it's cleaned automatically.14:53
Necoroand when? - running "bzr pack" even increased it ;P14:53
PengIt's cleaned when repacking is done.14:54
PengWhen you run "bzr pack" or auto-packing happens, it deletes everything in obsolete_packs, copies the current packs and indexes to it, and then does the packing.14:55
jamhowdy all15:13
PengWait, so is bialix just on vacation or leaving permanently?15:16
=== mw|out is now known as mw
jamPeng: well, last year he took "vacation" for a short time and came back15:18
jamNot sure how long it will be this time15:18
PengHe said he was leaving permanently last time?15:18
jamno, that he was taking a break/vacation, which is what he said at the beginning of this thread, unless it has changed15:19
PengOk.15:20
PengHis message sounded very final though.15:21
jamPeng: it does a bit, now that I've re-read it. We'll see, though. I seem to recall him sounding like he would be going away fairly permanently last time, and then he seemed to come back rather quickly.... It would be a shame to loose him15:23
=== mrevell_ is now known as mrevell
* lamont wonders about .bzr.log and when/why it comes to exist15:35
datoalways afaik15:35
lamontso..  when does bzr create it in the tree, instead of $HOME?15:40
datohm, I was talking about the one in ~15:42
black_is there a way to push or otherwise backup an entire repository?  can you simply copy a repo and all it's branches to another computer and then reasonably expect to be able to push and pull from the same rep/branches it was copied from?15:49
black_curious how other people were handling this15:51
jamlamont: the only time I've seen it show up in the tree is when running a test which sets $HOME to $CWD16:06
lamontjam or if $HOME is unset or equal to "", it would appear.16:07
lamontmy case was the former16:07
statikblack_: yes, you can16:22
korpiosblack_: yeah, I've been wondering the same thing16:29
black_I just figured it out16:35
black_there is a plugin to do it16:35
black_repo-push16:36
Noiais there a way to pass the password as part of an alias when performing a commit?16:51
NoiaI commit and update a whole lot, and one of the slowest things is typing my password >.<16:56
james_wNoia: over ssh>16:57
Noiayea, bzr+ssh://16:57
james_whave you though about ssh-agent?16:58
Noiassh-agent?17:01
james_wah, sorry, you need keys set up to do that, but it is a whole lot easier in the long run17:02
Noiahmm17:04
=== thekorn_ is now known as thekorn
NoiaI quite like this way of developing thugh17:07
NoiaI have a server which has the repo, then a development server and a production server, both of which build off the same repo17:08
Noiaso when I develop something I just push to the repo, and update the dev server, then when I want to roll out I just update the production server17:08
Pengjelmer: bzr.dev isn't compatible with bzr-svn 0.4.9 anymore. What should I do? Use a different version of bzr? Is bzr-svn's 0.4 branch stable now?17:17
ubotuNew bug: #220453 in bzr-gentoo-overlay "Branching a read-only HTTP branch (with no working tree) fails with bzr-1.4" [High,Confirmed] https://launchpad.net/bugs/22045317:22
=== kiko-afk is now known as kiko
malepthi, I've been attempting to install an HTTP smart server via fastcgi using the user guide, and I keep hitting a "NotBranchError" when trying to branch it (using 1.4rc2)18:20
=== mw is now known as mw|food
=== mw|food is now known as mw
jelmerPeng: no, there's nonthing non-experimental you can use with bzr.dev20:44
PengThat's unfortunate.20:45
PengOn the off-chance the PPA works, I could use the system version when I need bzr-svn.20:46
PengI'm about to wander off, but.20:46
PengHow major are the changes necessary to make 0.4.9 work with bzr.dev?20:46
* Peng wanders off.20:47
jamPeng: I'm sure it is probably rather minor, do you know what the error is?20:47
jelmerPeng: I don't know, 0.4 may not be compatible with bzr.dev yet either20:47
Pengjam: Err.20:48
Pengjam: From knit.py, "ValueError: No default access_method or index any more".20:48
jelmerPeng: that should be a pretty easy fix to backport20:49
jelmerthere's a couple of other ones I think though20:49
jamI think it just requires passing a single parameter20:49
jelmerjam: no, it relied on default arguments that lifeless removed in KnitVersionedFile's constructor20:50
PengOh, I didn't notice it's a VersionedFile thing. Lots of changes there...20:50
* Peng wanders off now, for realz!20:50
jamjelmer: which means you need to pass the parameter :)20:50
jam(/argument)20:51
jelmerjam: I ended up using a different function to create the knit20:51
jelmersince the only thing way to construct a knit index involves private classes20:51
jelmerI wouldn't mind if bzr releases were less often, that would save me from doing bzr-svn releases as often20:58
jelmerI'll try to do one before 1.4.0 is released though20:59
radixjelmer: is it actually necessary to do bzr-svn releases for every single bzr release?21:02
radixis it using internal bzr APIs that change every release?21:02
jamradix: we have had a tendency to break bzr-svn, we maintain "client" compatibility, but bzr-svn tends to hook in a bit deeper as an "implementor"21:03
jamso if we add an optional parameter, it needs to handle it21:03
radixOK21:03
radixactually I'm more annoyed with bzrtools breaking for every release:)21:04
malepthrm, I fixed my fastcgi problems (I think), but I've hit an AttributeError when trying to branch from the http smart server-enabled branch: http://dpaste.com/46365/21:05
abentleyjam: We don't do a very good job at maintaining client compatibility either.21:05
foomdoes ianc's benchmark suite have a webpage of historical results somewhere?21:06
jamabentley: we historically have done a fairly decent job at it, I think in the last few releases we've stopped trying as hard21:06
foomI ran across benchmark.bazaar-vcs.org but it seems to be dead.21:06
abentleyjam: beg to differ.21:06
malepthas anyone seen that particular error before?21:06
abentleyPretty much every release breaks something, and those that don't usually deprecate something.21:07
jelmerradix: yes, because bzr breaks the API every release (one exception so far in the history of bzr-svn)21:08
radixabentley: deprecations are great, I love deprecations21:09
Pengjelmer: Was the exception 1.3.1? :P21:09
abentleyradix: Most end-users don't.21:09
jamabentley: I don't consider a deprecation a strict api breakage, though argubly the 'released' bzr should disable the deprecation warnings by default21:09
jelmerPeng: no, 1.221:10
radixabentley: well, I don't know about user-facing things, I'm assuming we're only talking about APIs21:10
abentleyjam: I made a significant rewrite of graph-ancestry for bzrtools 1.4 just to avoid a deprecation warning.21:10
radixhowever, I do think deprecations are great compared to immediate breakage :)21:10
abentleyradix: If I use a deprecated API, there are user-facing consequences.21:10
radixabentley: what are those?21:11
abentleyradix: A deprecation warning is emitted.21:11
jamradix: a warning that you are usinga deprecated function21:11
radixabentley: IMO all python application mainpoints should filter out DeprecationWarning21:11
radixthe only ones that shouldn't be are UserWarning (I guess)21:11
abentleyradix: wearing my plugin author hat, that's not really relevant to me.  bzr's deprecation handling is what it is.  I try to cope.21:12
radixI guess I was just curious if bzrlib's API is breaking all the time *without* going through a period of deprecation21:12
abentleyradix: Have a look at NEWS.21:13
radixabentley: ok, then switch back to your bzr developer hat and add a filter for DeprecationWarning in main :-)21:13
jelmerradix: it does for some APIs21:17
jelmerradix: but bzr-svn touches a couple of core parts of bzrlib21:17
radixjelmer: right, yeah, I understand bzr-svn is rather "deep"21:17
radixjelmer: thanks21:17
PengBa, like 5-10 seconds of network access to download one trivial revision. :P21:36
PengBah*21:36
=== kiko_ is now known as kiko
ubotuNew bug: #220806 in bzr "PyCurlTransport doesn't define the _remote_is_at_least_1_2 property" [Undecided,New] https://launchpad.net/bugs/22080623:06
igcmorning all23:13
abadger1999Have there been any backwards incompatible API changes to bzrlib since 1.1?23:41
abadger1999I saw that there's going to be some deprecations in 1.4 with removal probable in 1.5.23:42
abadger1999Just checking if I missed anything else.23:42
beunoabadger1999, I don't know of the top of my head, but a quick glance at NEWS should tell you23:42
abadger1999Ah, good point23:43
beuno:)23:43
LaserJockis there a particular reason why a bzr pull would be giving bzr: ERROR: Not a branch: for a LP branch?23:45
beunoLaserJock, are you in the branch's dir?23:45
LaserJockyeah ... thought so23:46
fullermdWhat version?23:46
LaserJock1.3.1rc123:46
fullermdProbably not the smart probing thing then.23:48
LaserJockhmm, I did do a bzr reconfigure --branch23:49
LaserJockdoes that matter?23:49
abadger1999Darn it, there is but it's not a major break.23:49
fullermdNot directly, I wouldn't think.  But it may leave you with a parent location that's not what you want.23:49
* abadger1999 figures out how to let the bug reporter persuade him to update over his better judgement.23:50
LaserJockif the little progress wheel on the left stops turning does that mean it's stalled?23:56
* abadger1999 reads scrollback and sees that abentley and jam were talking about exactly his problem earlier.23:59
jamabadger1999: I would never discuss your problems in public :)23:59

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