| luke-jr | mwhudson: I mean when I 'rm a', 'bzr status' lists it as deleted and 'bzr commit' removes it from the repository | 00:00 |
|---|---|---|
| luke-jr | I don't want that. | 00:00 |
| luke-jr | rather, I want bzr to leave it alone like svn does | 00:00 |
| lifeless | luke-jr: there isn't a global option for this at the moment. I wanted to make it be like svn but got shot down on the mailing list | 00:03 |
| luke-jr | wtf ☹ | 00:03 |
| luke-jr | is there a not-so-global option? | 00:03 |
| lifeless | luke-jr: you can supply --strict to commit, and it will cause missing files to be considered an error | 00:03 |
| luke-jr | no way to automatically use --strict? | 00:04 |
| luke-jr | wait, an error? ☹ | 00:04 |
| luke-jr | why can't it just ignore it⁇ | 00:04 |
| ScottK | Is there a bzr command that just pushes back where the code was pulled from? | 00:04 |
| lifeless | ScottK: bzr push :parent | 00:04 |
| ScottK | lifeless: Thanks. | 00:04 |
| lifeless | luke-jr: well its code, anything is possible. I'm just describing what the current code does, and that I wanted to make new files and missing files be treated symmetrically, but didn't manage to get consensus on the list for this | 00:06 |
| lifeless | luke-jr: you're welcome to dig up that thread and post referring to it. Support from users would be good :P | 00:06 |
| fullermd | You could automatically use strict by just setting up an alias. | 00:08 |
| luke-jr | fullermd: an error blocks commits, I presume- | 00:09 |
| luke-jr | I just want the files not present in my WC | 00:09 |
| luke-jr | yet not delete them from the repo | 00:09 |
| luke-jr | and still be able to commit changes | 00:09 |
| mwhudson | oh well, that's less likely to win favour | 00:10 |
| mwhudson | the idea of commit is that it records what's on disk | 00:10 |
| luke-jr | it doesn't go trying to add my temp note files] | 00:11 |
| luke-jr | -.- | 00:11 |
| mwhudson | true, that's why i have commit --strict on by default... | 00:11 |
| luke-jr | … | 00:11 |
| luke-jr | so how do I get that? | 00:12 |
| luke-jr | better an error than remove I suppose | 00:12 |
| lifeless | luke-jr: there is a plan, for 'views' which will be a WT setting that says what files to have present on disk; when that is implemented you could use it to get rid of some files from disk without having commit remove them from the branch | 00:14 |
| lifeless | luke-jr: its not implemented yet, I'm just letting you know that its planned | 00:14 |
| delaney | is there anyway to make local commits the default with TortoiseBzr? | 00:46 |
| === kiko is now known as kiko-zzz | ||
| lifeless | http://paste.ubuntu.com/108059/ - currnet knit vs gc with 1G corpus | 01:07 |
| mwhudson | seems a bit better :) | 01:09 |
| mwhudson | is the "how do we make gc stream" question addressed yet? | 01:09 |
| NfNitLoop | are there known issues with bzr blame? | 01:10 |
| NfNitLoop | I ran blame on a repo that I've branched from svn. | 01:10 |
| NfNitLoop | bzr blame says a line was last changed in r1 | 01:10 |
| NfNitLoop | but when I svn blame the repo, I find otherwise. | 01:10 |
| NfNitLoop | (yes, I know svn rev#s are different from bzr rev#s) | 01:11 |
| NfNitLoop | What I seen in svn is that the line has been changed since it was created. bzr blame leads me to believe that it has been the same since its initial revision. | 01:12 |
| spiv | NfNitLoop: no issues like that. | 01:12 |
| spiv | NfNitLoop: but bzr-svn will have recalculated all the diffs between revisions. | 01:13 |
| lifeless | mwhudson: well, just compress on the fly | 01:13 |
| spiv | NfNitLoop: and so it's possible that it's calculated a different (but equivalent) diff to svn for the same change to a file | 01:13 |
| lifeless | mwhudson: (as one possible answer) | 01:13 |
| NfNitLoop | OOOoooh. | 01:14 |
| NfNitLoop | Yes, I see, spiv. Thanks. | 01:14 |
| NfNitLoop | The file was copied in svn. | 01:14 |
| spiv | NfNitLoop: e.g. consider four lines "aabb" becoming "bbaa" | 01:15 |
| NfNitLoop | and svn keeps the history through copies. | 01:15 |
| NfNitLoop | and, IIRC, bzr doesn't? | 01:15 |
| spiv | NfNitLoop: did "aa" get deleted and re-added, or did the "bb" lines get deleted and re-added :) | 01:15 |
| spiv | NfNitLoop: oh, yes, that too. | 01:15 |
| NfNitLoop | yeah, that's it. | 01:15 |
| NfNitLoop | the diff is pretty simple. one line's boolean is getting switched between "true" and "false". | 01:17 |
| NfNitLoop | with no justification in comments or commit messages. | 01:17 |
| NfNitLoop | Anyway, thanks for the help! | 01:18 |
| luke-jr | does 'bzr mv' work with bzr-svn right, or does it just add? | 01:35 |
| === jfroy|work is now known as jfroy | ||
| === jfroy is now known as jfroy|work | ||
| enkrates794 | I filed a bug about a week ago and got a response asking for more info. I provided the info, but I'm not sure if I should do something else in launchpad to get a further response. Could someone take a look at the bug and let me know if I've missed something? https://bugs.launchpad.net/bzr/+bug/316196 | 02:17 |
| ubottu | Launchpad bug 316196 in bzr "Error adding iTunes library on OSX" [Undecided,Incomplete] | 02:17 |
| alevine | what's the easiest way to make a personal bzr repo that can be shared (preferably over http)? | 02:19 |
| alevine | with subversion I used the apache module | 02:19 |
| tecan | i have problems with bzr | 02:22 |
| nDuff | alevine, just push your repository to somewhere some web server is sharing | 02:23 |
| nDuff | alevine, no special web server module needed. | 02:23 |
| nDuff | alevine, (though if you want more performance, a "smart server" is available). | 02:23 |
| tecan | suse came with bzr 1.8 but i installed 1.6 and now everything is more complicated | 02:23 |
| alevine | nDuff, push it over...ssh? | 02:23 |
| tecan | its probably python 2.6 issues | 02:24 |
| alevine | thats very cool | 02:24 |
| nDuff | alevine, ...it's fairly common to use SFTP for uploads (yes, pushes or bound commits) and let third parties use HTTP to download. | 02:24 |
| asabil | alevine: you must know that http is way way slower than the smart protocols | 02:24 |
| nDuff | tecan, could you be more specific about the issues you're seeing? "everything is more complicated" isn't very actionable. :) | 02:25 |
| mwhudson | tecan: new bzr's work with 2.6, but 1.6 isn't very new | 02:25 |
| alevine | nDuff, asabil: thanks, performance is not an issue, mostly just for myself and for sharing code every once in a while | 02:25 |
| tecan | there is no where to download the latest tarballs ? | 02:28 |
| tecan | 1.6 is the latest i can get the source to | 02:28 |
| luke-jr | … | 02:31 |
| nDuff | tecan, http://bazaar-vcs.org/ | 02:32 |
| nDuff | erk | 02:32 |
| luke-jr | so what's the deal with file copies anyhow? | 02:35 |
| luke-jr | such a simple feature has no progress for years? | 02:35 |
| nDuff | luke-jr, merge semantics become *much* complicated when one supports copies -- such that one pretty much *has* to do unintuitive things some of the time. | 02:37 |
| nDuff | luke-jr, there's a pretty good argument to be made that supporting features that require you to do unintuitive things is bad. | 02:37 |
| nDuff | s/features/"features"/ | 02:37 |
| * igc lunch | 02:42 | |
| nDuff | luke-jr, ...I can see supporting copies inasmuch as "create a new file which looks at this old one for purposes of blame and log operations", and that's probably a pretty reasonable feature request... | 02:42 |
| thumper | where can I find the default ignore list? | 02:43 |
| thumper | as in the files that are ignored by default | 02:43 |
| nDuff | luke-jr, ...but having merges not change the new version under any circumstances probably isn't end-user-intuitive behavior either. | 02:43 |
| nDuff | thumper, ~/.bazaar/ignore | 02:46 |
| thumper | nDuff: ta | 02:50 |
| thumper | anyone know where the bzr svg icon lives? | 02:56 |
| thumper | I want it for a presentation | 02:56 |
| jam | http://bazaar-vcs.org/Icons I think | 02:59 |
| jam | thumper: http://bazaar-vcs.org/LogoOptions | 02:59 |
| thumper | jam: fantastic, ta | 02:59 |
| thumper | jam: is there an svg without the text? | 03:01 |
| jam | thumper along the bottom | 03:01 |
| jam | bazaar192.svg? | 03:01 |
| jam | or you can look here: http://bazaar-vcs.org/LogoOptions?action=AttachFile | 03:02 |
| jam | there seem to be quite a few .svg files | 03:02 |
| luke-jr | nDuff: screw merge stuff, that's secondary to actually recording a copy | 03:30 |
| nDuff | luke-jr, ...if you tell users you'll record a copy but don't then give them the behavior they expect when merging between a branch where a copy happened and a branch where the file was changed (whatever that "behavior they expect" may be), that's just asking for surprised/unhappy users. Heck, there'd be likely folks who'd expect copy+rm to behave the same way as a mv -- lots of other SCMs do it that way, after all. | 03:33 |
| nDuff | ...but anyhow, it's been discussed on list; see the thread [RFC] Tracking file copies | 03:34 |
| luke-jr | cp+rm = mv | 03:34 |
| nDuff | ...so are changes in the original going to impact copies on merge or not? (And, more to the point, will changes in the *copies* impact the *original* on cherrypick? If so, which copy?) "Only if the original has since been deleted" means you've got a new set of corner cases. | 03:36 |
| nDuff | converting cp+rm to mv *only if the original was deleted within the same commit* is a reasonable behavior, but it's not quite the same thing as the generalization cp+rm=mv. | 03:38 |
| luke-jr | changes to both copies could be merged | 03:38 |
| luke-jr | creating conflicts if necessary | 03:39 |
| nDuff | whether that's appropriate depends on why you did the copy. If you're copying a template out to create a new file you're going to modify, merging changes from the new versions back to the template is absolutely wrong behavior. | 03:39 |
| luke-jr | yes, ok | 03:40 |
| luke-jr | so cp+rm might not always be = mv | 03:40 |
| luke-jr | so keep cp+rm separate from mv | 03:40 |
| nDuff | anyhow, see the mailing list thread | 03:40 |
| luke-jr | how about just having changes to a copied file depend on the copy changeset? | 03:41 |
| luke-jr | IMO, cherry picking is a less needed feature than copying | 03:43 |
| nDuff | luke-jr, well, you might ask jelmer how the spec is coming along sometime. | 03:50 |
| thumper | is there a nice page explaining how to get bzr working with eclipse? | 03:52 |
| thumper | I have some pug people asking | 03:52 |
| thumper | and I don't use eclipse | 03:52 |
| luke-jr | thumper: open a terminal and Alt-Tab | 03:55 |
| luke-jr | (why anyone would use eclipse is beyond me, it sucks) | 03:55 |
| * thumper looks strangly at luke-jr | 03:55 | |
| nDuff | there's a bzr plugin for Eclipse | 03:55 |
| thumper | nDuff: yes there is | 03:55 |
| thumper | nDuff: is it packaged for ubuntu? | 03:56 |
| nDuff | ...though I haven't used it recently; last time I tried, it didn't support linked resources. (They've fixed that since, but not early enough for my purposes) | 03:56 |
| thumper | is bzr-xmloutput? | 03:56 |
| * thumper wishes for bzr-eclipse and bzr-xmloutput to live in the ~bzr PPA | 03:58 | |
| === mark1 is now known as markh | ||
| vila | hi all | 07:12 |
| tecan | ERROR: The user tecan has not registered any SSH keys with Launchpad. | 07:38 |
| tecan | how do i fix this ? | 07:38 |
| bob2 | login via the web interface and add an ssh key | 07:40 |
| tecan | where | 07:41 |
| tecan | i dont see ssh anywhere | 07:41 |
| tecan | oh o found it | 07:43 |
| kiko-zzz | morning | 07:48 |
| tecan | morneng | 07:52 |
| === kiko-zzz is now known as kiko | ||
| awilkins | Where is the keyserver where Launchpad keeps it's PPA signing keys? The latest bzr packages are signed with keys I can't find and apt is refusing to associate with them :-) | 08:34 |
| igc | ping vila | 08:38 |
| vila | igc: pong | 08:38 |
| igc | vila: any thoughts on jam's comments re log --include-merges option naming? | 08:38 |
| igc | he voted tweak but I think we should get the name right first | 08:39 |
| igc | in particular, how useful would depth control be? | 08:39 |
| igc | e.g. .. | 08:39 |
| igc | log -n1 => flat | 08:39 |
| vila | which thread ? I'm a bit out of loop on log for the last few days :-/ | 08:39 |
| igc | log -n0 => fully nested | 08:40 |
| * igc looks | 08:40 | |
| vila | I read that I think, I'd prefer --merge_depth to be: 0: flat, -1 fully nested or something like that | 08:40 |
| fullermd | You mean depth like how many levels deep to show merges? | 08:40 |
| vila | i.e. matching our internal merge_depth so that it can be used more broadly | 08:41 |
| vila | fullermd: yes | 08:41 |
| fullermd | That strikes me as way too fiddly. It seems like you'd need really contrived cases for a user to actually know what to do with it other than "none" or "all". | 08:41 |
| vila | I encounter the use case yesterday in a loom where I wanted mainline but at depth 1 | 08:42 |
| igc | vila:https://lists.ubuntu.com/archives/bazaar/2009q1/051802.html | 08:42 |
| igc | fullermd: it a shame we don't have optional parameter values to options | 08:43 |
| igc | then log --nested could mean all | 08:43 |
| vila | and depending on the workflow you use I'm sure there are other such use cases *other* than mainline of full | 08:43 |
| vila | s/mainline of full/mainline or full/ | 08:43 |
| fullermd | Well, you could add a --nest-level to supplement it. That's not a major objection. | 08:43 |
| igc | and log --nested=2 could mean show just 2 levels (total or beyond the mainline depending on one's thought pattern) | 08:44 |
| fullermd | Yah, but it seems like it would have to be a very specific workflow, AND you'd have to know that it was universally followed. | 08:44 |
| vila | igc: Ha ! That thread ! Exactly the one I wanted to comment in priority | 08:45 |
| igc | fullermd: with PQM not showing the real author, I think was suggesting looking down just one level would be nice | 08:45 |
| fullermd | IMO, by the time you have the need and environment to be able to do that level of control, you're in a position to also want much more control over the rest of the output too. | 08:45 |
| vila | So, first of all, I still think we should refactor log to be able to pass parameters to log formatters *before* adding generic parameters to log | 08:45 |
| vila | i.e. not all parameters all relevant for all log formatters | 08:46 |
| igc | vila: I'm still not sure about that | 08:47 |
| vila | Second: I think there are more ways to select and present the revisions than just mainline and full, in the broader perspective, any sub-graph may be interesting | 08:47 |
| igc | vila: I think it ought to be simple for a plugin to define a new LogFormatter like "email" or "xml" | 08:47 |
| vila | oops, forget Second for a moment then, let's discuss first first | 08:47 |
| igc | and making every log-formatter see most parameters seems to be introducing complexity to the "create a new LogFormatter" process | 08:48 |
| vila | IMHO LogFormatter deals mainly with formatting *one* revision and everybody tends to think about them only in that context | 08:48 |
| vila | That's no the entire truth | 08:49 |
| igc | vila: also, I think the immediate priorities need to be: | 08:49 |
| vila | LogFormatter also deals wiht the graph of revisions they are presenting | 08:49 |
| igc | * make it fast so people can use it on large projects | 08:49 |
| igc | * provide the blatantly missing functionality (like log DIR) | 08:49 |
| vila | igc: I understand your priorities, that's one reason I stepped back on refactoring log (the other main one being that I had an already full plate with other issues and my changes to log can stay private for the time being) | 08:50 |
| vila | Regarding your priorities, "fast" can be done without refactoring, "DIR" I don't think so | 08:51 |
| igc | vila: I'm not rejecting your idea, I just don't want to hold up improvements than are arguably orthogonal | 08:51 |
| vila | igc: full agreement | 08:52 |
| igc | vila: so returning to my UI question, I think fullermd's suggestion has merit: namely ... | 08:52 |
| vila | but I think *some* of them are not that orthogonal :) | 08:52 |
| igc | leave the option called --include-merges (and add --nest_level later) | 08:53 |
| jelmer | luke-jr, That's a known bug in that rc, should be fixed in the 0.5 branch | 08:53 |
| vila | My main concern is that IMHO we're introducing options that we may deprecate later or force some log formatters to handle things they don't want to care about | 08:54 |
| igc | vila: but perhaps the LogFormatter constructor should take a nest_level now. | 08:54 |
| igc | understood | 08:54 |
| igc | but it's pretty damn easy given depth is a field in every record passed to a LOgFormatter to format | 08:55 |
| vila | igc: nest_level to constructor sounds good to me | 08:55 |
| igc | checking if n <= m isn't more complex than if prefer_merge_revisions IMO | 08:56 |
| fullermd | Can't the formatters just eat whatever args you give them and only bother looking at the ones they care about? | 08:56 |
| fullermd | It seems insane to have to explicitly add each possible arg, even if they'll never care about it... | 08:57 |
| vila | if it's under log formatter control I'm happy enough, it means they can decide to handle the option or not, or even reject the option | 08:57 |
| igc | but it implies lots of common filtering code repeated in each log formatter | 08:57 |
| vila | fullermd: we are not there yet, but the idea is to pass unprocessed option to log formatter which in turn can pass back unprocessed option for error handling | 08:58 |
| igc | rather than a log formatter having a clear responsibility, i.e. "format this record" | 08:58 |
| vila | igc: that's why we want a base class with all the utilities ! | 08:58 |
| vila | You're back to reducing log formatter to "format this record" that's not their only responsibility IMHO | 08:59 |
| igc | it is currently | 08:59 |
| igc | they don't really so a graph ... | 08:59 |
| vila | no it isn't : look at begin_log end_log | 08:59 |
| igc | just a sequence of tuples (including a depth field) | 08:59 |
| igc | begin_log and end_log are hooks as I understand them for opening/closing headers/footers, yes? | 09:00 |
| vila | of course the LogRevision are called in sequence but that's also a part that could/should go under the lf responsability | 09:00 |
| igc | and/or opening/closing resources perhaps | 09:00 |
| vila | That's why I say the lf responsability is currently unclear, parts of it being implemented by the log module, I think that's wrong and blurry things | 09:01 |
| vila | igc: Have a look at the xnloutput Log Formatter for example | 09:02 |
| * igc looks | 09:03 | |
| vila | It's a lf that consider itself responsible for the whole log display, not only each individual revision display, because it must balance the xml flags for each level | 09:04 |
| vila | so it must understand the whole graph (or tree if you prefer) | 09:04 |
| vila | You can argue that it could just use depth as an attribute and just format the whole as just a sequence... | 09:05 |
| vila | ...but that's not the point I'm trying to make :-) | 09:06 |
| igc | right | 09:06 |
| igc | so begin_log & end_log put out the <log> and </log> markers | 09:06 |
| igc | the rest looks like the usual HTML formatting dance :-) | 09:06 |
| igc | i.e. balancing of tags while outputting nested lists | 09:07 |
| vila | i.e. taking care of the whole formatting not only of the "format this record" | 09:08 |
| vila | that's my point | 09:08 |
| vila | end-log do a bit more than just putting out the </logs> (not <log>) marker, there is a stack to purge to | 09:10 |
| igc | it's format-this-record-in-the-context-of-what-I've-seen-already and ... | 09:10 |
| igc | unwind levels as we step outwards | 09:10 |
| vila | you can stop there, you said context | 09:10 |
| igc | vila: I guess I'm asking ... | 09:11 |
| igc | why would passing more to the log formatter help it? | 09:11 |
| igc | we don't pass through end-of-merge for example | 09:11 |
| igc | vila: would that make things easier say? | 09:12 |
| vila | what is end-of-merge ? | 09:12 |
| igc | a True/False field generated by tsort.merge_sort (along with rev-id, depth & revno) | 09:13 |
| igc | I suspect having it would help much | 09:13 |
| igc | it's not until you see the *next* depth that xmlformat will know the amount of levels to unwind | 09:13 |
| igc | s/would/wouldn't/ | 09:14 |
| vila | I think that giving more responbilities to lf, will make it easier them to access the data they need instead of relying on the log module to format them in a generic way | 09:14 |
| vila | Being able to decide at the lf level what 'revision' parameter is valid or not sounds like a solution to several problems you tried to address recently | 09:16 |
| vila | igc: Won't you be happier with get_view_revisions being specific to a log formatter ? | 09:17 |
| igc | I'll be happier when get_view_revision goes! | 09:18 |
| igc | it's a crap API! | 09:18 |
| vila | I think that will make the include_merges parameter useless for example | 09:18 |
| vila | igc: great, delegate to lf will make it less crap | 09:18 |
| igc | true, but so will fixing it :-) | 09:19 |
| igc | the mainline rev, revnos and include_merge parameters are all unnecessary IMO | 09:20 |
| igc | Branch.iter_merge_revisions is the way forward I feel | 09:20 |
| vila | except for the fact you need them to be reasonably fast, I entirely agree :) | 09:21 |
| vila | i.e. they are implementation details | 09:21 |
| vila | Branch.iter_merge_revisions ? IS there where you use a reverse parameter ? | 09:22 |
| igc | jam wanted a reverse parameter to it and I've submitted a patch along those lines but ... | 09:22 |
| igc | I'm not sold yet on reverse being meaningful at that level | 09:22 |
| vila | Can we please, please, stop using 'reverse', 'forward' and 'backward' have a meaning by themselves 'reverse'... always makes me wonders | 09:22 |
| igc | true | 09:23 |
| igc | so currently, reverse in log & missing calls sort_by_depth | 09:23 |
| vila | hmm, more than just that I think | 09:24 |
| igc | That feels a bit too fancy for Branch.iter_merge_revisions where forward/backwards makes a lot more sense | 09:24 |
| vila | off-topic forward without 's' and backwards with 's' always / | 09:25 |
| vila | s!/!?! | 09:25 |
| vila | lol, perl is noise :) | 09:25 |
| igc | no, I meant forward/backward | 09:25 |
| vila | ooh, you mean 'reverse' as used at UI level, I was meaning internally also | 09:26 |
| igc | vlia: anyhow, I need to have dinner now | 09:26 |
| igc | vila:^^ | 09:26 |
| vila | Enjoy your dinner :) | 09:26 |
| igc | so you're ok with --include-merges at the UI level & preferred_depth at the LogFormatter API level? | 09:27 |
| igc | vila:^ | 09:27 |
| vila | why preferred instead of just depth ? | 09:28 |
| vila | I'm ok for --include-merges | 09:28 |
| igc | you're right, just depth is good | 09:28 |
| igc | or levels | 09:29 |
| vila | Overall: I'm globally ok with your modifications anyway, it's just that I think some of them may be simpler *after* refactoring and some of them may make refactoring *harder* | 09:29 |
| vila | But since you'r the one spending the time on it, you get to choose :) | 09:29 |
| igc | :-) | 09:29 |
| vila | igc: And I'm perfectly fine that | 09:30 |
| vila | igc: And I'm perfectly fine with that | 09:30 |
| igc | cool - time to go. Thanks for the chat | 09:30 |
| vila | You're welcome | 09:30 |
| vila | jam: Ha ! Look who is blocking pqm now ! Welcome to the club :-) | 09:45 |
| NET||abuse | hi guys.. basic usage question, i've a little project on my laptop, i'm concerned for the hardware, how do i clone up to my server for backup? can i just sftp copy the whole versioned directory(working copy i guess) straight up to the server? | 09:51 |
| NET||abuse | or do i need to use a bzr instruction to do so? | 09:51 |
| pygi | NET||abuse, either bzr branch whateva on server works, or you can sftp things | 09:52 |
| pygi | or bzr push from local to server | 09:52 |
| NET||abuse | hmm, ok | 09:52 |
| NET||abuse | i'll have a look at it. | 09:52 |
| NET||abuse | hmm, missing page in the bzr docs,, http://bazaar-vcs.org/Scenarios/NewProject | 09:59 |
| pygi | NET||abuse, that Scenarios page is new :) | 09:59 |
| pygi | we're yet to work on it ;) | 09:59 |
| NET||abuse | so i can push to my server where it has no bzr repo setup, initi'd yet | 10:02 |
| vila | herb: It looks like you're the only losa around, can you have a look at PQM please ? | 10:06 |
| vila | herb: I meant when you come online... | 10:06 |
| NET||abuse | hmm, ok so branch from my local to remote doesn't work,, i did bzr branch ./ svn+ssh://me@host/path/to/new/bzr/dir and it throws error "bzr: ERROR: No repository present:" | 10:08 |
| NET||abuse | What i'm looking to do is move my current standalone branch on my local laptop, up to a dir on my webserver, and then have that act as the main branch for my work, i will be opening it up to someone else next week, so need it up there, and also worried my laptop is about to croak | 10:10 |
| NET||abuse | it's gotta a discreet nvidia NVS135M card in it, they're known to have issues, this is my 1st replacement from dell, the first one died and 5 engineer visits didn't fix it, so they just gave me whole new model, now last night during 10,000 bc :) the screen glitched like the last one had started to before it died... | 10:11 |
| NET||abuse | not good. | 10:11 |
| fullermd | I don't think you can branch into SVN... | 10:18 |
| fullermd | I don't even know if branch CAN target somewhere remote. Used to definitely not; can't remember if that was changed or not. | 10:20 |
| fullermd | Generally you just push anyway. | 10:20 |
| NET||abuse | umm, you see this is why i need to ask,, yeh, svn+ssh,, oops,, i'm not looking to push to svn, was looking to make a new bzr repo... so i just tried bzr ./ bzr+ssh://me@host/path/to/repo/to/create and it didn't like it,, error unkown command 'server' connection closed: please check connectivity and permissions | 10:28 |
| NET||abuse | unknown command wasn't 'server' just 'serve' still the error stands... | 10:29 |
| NET||abuse | so last effort,, i just tar.gz up the bzr repo directory,, then upload it. | 10:30 |
| NET||abuse | extract it on the remote server then try to point my local to it. | 10:30 |
| NET||abuse | or will they conflict? would i have to re clone/branch from the server back down to my local machine? | 10:30 |
| === asac_ is now known as asac | ||
| fullermd | Unknown command serve? That sounds like a *REALLY* old bzr on the far side... | 10:34 |
| fullermd | Taring it up should work just fine for backing it up. | 10:35 |
| === awilkins is now known as dr_barnowl | ||
| NET||abuse | fullermd: yeh, the far side is the old LTS ubuntu, dapper i think? | 10:39 |
| spm | vila: what seems to be the problem? One of your submissions appears to have succeeded about 20 minutes ago? | 10:39 |
| vila | spm: thanks for looking in to it, it looked like last *jam* submission was blocking the pqm, mine was just waiting | 10:40 |
| vila | spm: things seems fine now | 10:40 |
| vila | spm: did you do anything ? | 10:40 |
| spm | vila: cool. apart from looking? no. :-) Easiest fix I've done in ages :-) | 10:41 |
| vila | spm: pqm is just afraid by you then :) | 10:41 |
| spm | heh | 10:41 |
| vila | Or may be *I* just misread or read too soon... | 10:42 |
| spm | shrug - is no matter. when it gets stuck it's pretty easy to unstick - better to keep things flowing | 10:43 |
| dr_barnowl | fullermd: You can branch into SVN | 10:48 |
| dr_barnowl | fullermd: I had to "svn-versionize" a list of dated archive folders recently, which I did by committing them to bzr branches and pushing them to svn | 10:49 |
| === Pieter_ is now known as Pieter | ||
| fullermd | Well, I know you can push them in. I mean I don't think you can use _branch_ to do it. | 10:54 |
| fullermd | (actually, I thought you couldn't use push either, and there was some other command to create one ab ovo) | 10:54 |
| wgrant | You have to use bzr svn-push to create a new branch. | 10:57 |
| clemente | In latest bzr.dev: File "/home/w/bzr/oficial/bzrlib/ui/__init__.py", line 237, in make_ui_for_terminal: UnboundLocalError: local variable 'cls' referenced before assignment | 11:00 |
| vila | clemente: thanks, fix is on its way | 11:19 |
| nua | hi I'm having real trouble starting the bzr server, it breaks and I get a traceback: http://pastebin.com/m66382410 | 11:37 |
| nua | I'm using the standard install for ubuntu 8.10 | 11:37 |
| nua | which reports to be bzr 1.6.1 | 11:38 |
| lifeless | thats a bug in bzr-dbus which has been fixed since that release | 11:42 |
| lifeless | either uninstall bzr-dbus, or upgrade it, or have dbus running | 11:42 |
| ScottK | Sounds like a good SRU candidate then. | 11:48 |
| nua | hmm, now I'm just getting address already in use, I think that other attempt is still using it | 11:52 |
| frk2 | hello all | 12:02 |
| frk2 | had a question regarding the use of hooks in bazaar | 12:02 |
| frk2 | Im using a shared repository arch | 12:06 |
| frk2 | so basically everyone commits to a singular server | 12:06 |
| frk2 | to send commit notifications out do i have to configure bzr-email on every single desktop? | 12:07 |
| frk2 | configuring on the remote repo in .bzr/branch/branch.conf does not seem to work, configuring locally does | 12:07 |
| lifeless | bzr-email on te server, and push via bzr+ssh should work just fine | 12:13 |
| lifeless | gnight all | 12:13 |
| frk2 | but a bound commit does not | 12:13 |
| frk2 | lifeless, i can try to push and see if that works. But I have the branch bound to the server- a commit does not help | 12:14 |
| frk2 | guess you have gone off to bed :) gnite | 12:14 |
| Jc2k | frk2: you could try bzr-hookless-email as a workaround in the mean time | 12:22 |
| frk2 | Jc2k, whats that? | 12:22 |
| === dr_barnowl is now known as awilkins | ||
| Jc2k | frk2: it uses inotify (or just run it very frequently in cron) and looks at what changed and generates emails | 12:23 |
| frk2 | is it part of bzr tools now? | 12:24 |
| Jc2k | no | 12:24 |
| frk2 | so get it from lp directly? | 12:24 |
| Jc2k | bzr branch lp:bzr-hookless-email | 12:25 |
| Jc2k | its not a plugin, so no need to put it in .bazaar/plugins or anything | 12:25 |
| Jc2k | i've not used it myself, but i think debian are using it for their commit emails | 12:25 |
| frk2 | Jc2k, got it running- am guessing it uses sendmail or something to actually send the email | 12:31 |
| Jc2k | frk2: its based on bzr-email, so imagine its the same kind of thing as that | 12:32 |
| mtaylor | lifeless: coupla quick things about stacked branches... --stacked-on=lp:~mordred/wafflegrid/5.1-upstream doesn't work - doesn't recognize lp: syntax ... and also, that fails, so the push aborts, but not before it creates _something_ on launchpad | 12:33 |
| nua | I add the bzr PPA and got the latest version, all working fine now | 12:55 |
| nua | I was wondering how I require log-in to access the repositories if I'm using bzr serve? it seems like anyone can checkout the code | 12:56 |
| frk2 | nua, you do not, i think | 12:58 |
| frk2 | thats why its read obly | 12:58 |
| frk2 | only | 12:58 |
| frk2 | unless explicitly enabled | 12:58 |
| frk2 | i use bzr+ssh | 12:58 |
| nua | ok, so I basically have to use bzr+ssh if I want authentication? | 12:59 |
| nua | that's ok, but it means I get really ugly urls | 12:59 |
| frk2 | AFAIK, yes | 13:00 |
| nua | would I create an ssh account for each collaborator (I'd rather not) or could I force them to use a single bzr user and authenticate on their ssh keys? | 13:00 |
| nua | frk2: what about https? | 13:07 |
| awilkins | nua: You can use http and your http server will take care of auth for you if you configure it | 13:12 |
| nua | awilkins: ok thanks, I think I'll give that a go | 13:13 |
| awilkins | nua: ssh also works with a single ssh user as long as you put each users public key on your authorized_keys file | 13:13 |
| nua | awilkins: I think http sounds like the most sensible route | 13:14 |
| awilkins | nua: It's very easy for read-only access | 13:15 |
| awilkins | nua: It'll work out of a dumb http server ; write-access takes a little more work | 13:15 |
| nua | awilkins: I can run a smart http server by using bzr+http:// right? | 13:15 |
| awilkins | nua: You can _access_ a smart server by specifying bzr+http:// | 13:16 |
| awilkins | nua: To run one you need to configure the server to pass requests to bazaar through WSGI | 13:16 |
| nua | awilkins: ok, but I can write to the sever over http/https? | 13:17 |
| awilkins | nua: Yes, as long as the smart server is configured | 13:17 |
| awilkins | Which web server are you using? | 13:18 |
| nua | awilkins: I usually use apache or lighttpd... just looking at which to set up now | 13:18 |
| nua | awilkins: do you know of any guides on how to set up bzr smart server and http? | 13:19 |
| awilkins | I wrote the page at http://bazaar-vcs.org/ServerGuide/IIS | 13:19 |
| awilkins | I think there are hints for apache in the docus somewhere | 13:19 |
| awilkins | http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#id80 | 13:20 |
| nua | awilkins: yeah, just found that :) | 13:20 |
| awilkins | I had to fix the code to make it work with IIS :-) | 13:21 |
| awilkins | Half IIS's fault though | 13:21 |
| vila | haaa, just finish talking with igc, saw lifeless less than an hour ago, now poolie is joining... Did I enter the TZ ? (Twilight Zone :) | 13:26 |
| vila | Hi poolie :-) | 13:26 |
| poolie1 | hello vila | 13:29 |
| === poolie1 is now known as poolie | ||
| igc | hi poolie | 13:33 |
| igc | jam: thanks for the review re the dotted_revno_to_revision_id patch. Much appreciated | 13:33 |
| poolie | hello igc, you're up late | 13:33 |
| poolie | i think | 13:33 |
| igc | poolie: my hours are all the place right now | 13:34 |
| igc | 7am start yesterday, 6am finish, hospital visit in between | 13:34 |
| igc | I sleep when I tired currently | 13:35 |
| igc | jam: I'd also love a review of the iter_merge_sorted_revision patch if you have time/interest | 13:36 |
| igc | poolie: re log --include-merges, I think I'd prefer log --levels N to control how many levels are displayed | 14:09 |
| igc | N=0 would be "all of them"; N=1 would be a flat list | 14:10 |
| igc | together with a shorthand of -n, I think it would work well ... | 14:10 |
| igc | e.g. log -n1 seems better than log --no-include-merges | 14:11 |
| igc | likewise log --short -n0 is easier than log --short --include-merges | 14:11 |
| igc | also, when logging from a merge revision, it's the number of levels down that matters, not mainline vs merge revision display | 14:12 |
| igc | poolie, jam: thoughts? | 14:12 |
| igc | fullermd suggested having both --include-merges and nest_levels | 14:13 |
| igc | once we have the latter though, the former seem redundant | 14:13 |
| aquarius | I had a conflict in my branch when I merged another branch into it, on a file foo/bar/baz. I've done "bzr rm foo" (it doesn't need to be there any more), but bzr still says the conflict is present | 14:13 |
| aquarius | how do I unconfuse it (and me)? | 14:14 |
| poolie | poolie: that sounds nice, um | 14:14 |
| poolie | i would have thought -n0 means "no" :-) | 14:14 |
| poolie | actually seriously 0 means "none" | 14:14 |
| poolie | also, being indented one level does not precisely correspond to "one step away" in the actions the user took | 14:15 |
| poolie | though arguably it does when you pull the dag around a bit | 14:15 |
| poolie | shorter options == better | 14:15 |
| poolie | does that help at all? | 14:19 |
| igc | poolie: I think 0 meaning all is ok; asking for zero levels isn't very useful :-) | 14:28 |
| poolie | ah | 14:28 |
| poolie | if you're counting from kind of column zero on the screen | 14:28 |
| poolie | then yes | 14:28 |
| igc | well, for log at least! | 14:28 |
| igc | so I guess we can have n mean either total number of levels or number of nested levels | 14:29 |
| igc | do you have a preference? | 14:29 |
| igc | if # of nested levels, then -n0 means flat & we need a # or symbol for all | 14:30 |
| igc | log -n all is actually ok btw | 14:31 |
| igc | we don't have int options, just strings we parse into ints it turns out | 14:31 |
| igc | poolie: ^^ | 14:31 |
| igc | n fact, -n all would work regardless of what exact semantics we gave the numbers | 14:32 |
| poolie | igc, that makes sense, i think -n0 is nice and short to type to mean everything | 14:33 |
| igc | me too | 14:33 |
| poolie | so -n0 would be the default? | 14:33 |
| igc | it's format specific | 14:33 |
| igc | the -n just overrides the default | 14:34 |
| igc | that way we keep c ompatibility for existing users | 14:34 |
| poolie | ok | 14:35 |
| poolie | sounds good | 14:35 |
| igc | internally, -1 will mean "let the format decide" and it will be the default | 14:35 |
| luke-jr | jelmer: which bug? | 14:41 |
| bakunin | I'm trying out bzr on my Windows box towards our Subversion repository, but I haven't been able to find out how you specify username and password towards the subversion repository. Any pointers to documentation about this? | 14:42 |
| luke-jr | jelmer: isn't the difference between "Fix Committed" and "Fix Released" that the latter is actually in a release? | 14:46 |
| luke-jr | jelmer: BTW, any chance we can get a 'bzr svn-cp' or such that pushes a 'svn cp' upstream? >_< | 14:50 |
| luke-jr | maybe represent it in bzr through a 'copied from' property or such | 14:51 |
| luke-jr | (until it has proper copy support) | 14:51 |
| vila | igc: catching up ! +1 +1 +1 for -n !! Including 0 for all | 15:04 |
| igc | vila: thanks. I think it will work well | 15:04 |
| vila | I also prefer that to having several options | 15:04 |
| vila | igc: "internally, -1 will mean "let the format decide" and it will be the default" :-) | 15:08 |
| vila | Let the format decide ftw ! :-) | 15:08 |
| igc | and for backwards compatibility :-) | 15:08 |
| vila | same boat ! More room to improve other lfs :-) | 15:09 |
| === phinze_ is now known as phinze | ||
| nua | does this mean I need to edit the bzrlib source?? http://pastebin.com/m533f12af | 16:26 |
| === beaumonta is now known as abeaumont | ||
| tro | bakunin: use the HTTP method of specifying username/password. ie: svn://username:password@svn.repo.com/path/to/repo/trunk | 16:36 |
| awilkins | nua: I think the WSGI handler that is posted is a bit out of date | 16:40 |
| awilkins | nua: When I upgraded on Windows I had to change the logging parameters | 16:40 |
| bakunin | @tro Will the same work for a http URL? | 16:43 |
| tro | bakunin: yes | 17:09 |
| pickscrape | Given a revision ID, what is the quickest way in bzrlib to determine the number of parents that the revision has? (i.e. whether or not it is a merge) | 17:13 |
| garyvdm | pickscrape: http://pastebin.com/d2ec223ca | 17:22 |
| pickscrape | garyvdm: thanks for that | 17:23 |
| === jfroy|work is now known as jfroy|emo | ||
| poolie | vila: hello | 17:46 |
| bakunin | tro: Thanks a lot. It worked. I guess this is how basic authentication is handled | 18:00 |
| === fawek_ is now known as fawek | ||
| === sabdfl1 is now known as sabdfl | ||
| luke-jr | how do I get teh 'svn revno' with bzr? | 18:23 |
| james_w | luke-jr: recent bzr-svn will put it in the output of "bzr log" | 18:26 |
| luke-jr | james_w: programmically | 18:27 |
| james_w | luke-jr: dunno | 18:28 |
| james_w | luke-jr: take a look at bzr-svn's source for how it implements that | 18:28 |
| luke-jr | :/ | 18:29 |
| james_w | show_foreign_revid perhaps | 18:29 |
| luke-jr | s/programmically/from a shell script/ | 18:30 |
| * garyvdm wishes he could use python 3.0's nonlocal statement... | 18:45 | |
| lorph | is tortoisebzr usable yet | 18:58 |
| garyvdm | lorph - I use it. | 19:03 |
| garyvdm | Heh - He left allready :-( | 19:04 |
| === jfroy|emo is now known as jfroy|work | ||
| mrooney | I am using bzr-svn to attempt to branch a rather large svn repository, but it doesn't seem robust enough to ever make it the whole way through. Is there a way to continue/resume this process? | 19:24 |
| mrooney | It seems to get a few thousand revisions in and then die and I have to start all over. | 19:25 |
| james_w | hey mrooney | 19:25 |
| mrooney | james_w: hey! | 19:25 |
| james_w | you can "bzr branch -r 1000" | 19:25 |
| james_w | then "bzr pull" 1000 revisions at a time | 19:25 |
| mrooney | james_w: ahh that sounds perfect, so if I branch 1000 and then the next pull fails, what state is it left in, the original before that pull? or is it still broken? | 19:26 |
| james_w | it should be left as it was before the pull | 19:26 |
| james_w | bzr pull -r 2000 | 19:26 |
| james_w | bzr pull -r 3000 | 19:26 |
| james_w | etc. | 19:26 |
| james_w | should stop it doing too much in one go | 19:27 |
| mrooney | james_w: thanks so much, this seems good | 19:30 |
| james_w | cool | 19:30 |
| mrooney | I figured an easy way to back up our SVN repositories incrementally was just to branch once from another machine via bzr-svn, and then pull every night | 19:30 |
| mrooney | james_w: does that sound sane? | 19:30 |
| james_w | seems reasonable | 19:30 |
| mrooney | excellent | 19:31 |
| mrooney | It would also probably help if I wasn't doing this over wifi :) | 19:31 |
| asabil | btw, does bzr have a way to see the diff/log of changes that where retrieved using a pull ? | 20:00 |
| garyvdm | asabil: There is before you pull. You can use missing to see what revisions, and diff pull_branch for diff | 20:03 |
| garyvdm | asabil: bzr does not remember what the tip revid was before the pull | 20:04 |
| asabil | it would be really very useful if it did | 20:05 |
| amanica_ | asabil: you can tag it before you pull | 20:28 |
| === abadger19991 is now known as abadger1999 | ||
| amanica_ | or maybe we can do an implicit tag before pulling | 20:28 |
| amanica_ | eg BEFORE_LAST_PULL | 20:29 |
| amanica_ | maybe this would be possible to do with a plugin... | 20:29 |
| lifeless | mtaylor: file a bug on the stacking-on failure please | 20:35 |
| garyvdm | Is there a way to specify the bound branch? | 20:36 |
| garyvdm | e.g. bzry push -d --bound_branch-- | 20:37 |
| lifeless | garyvdm: bzr bind <url> | 20:37 |
| lifeless | garyvdm: oh; :master I think | 20:37 |
| garyvdm | lifeless: re:bind Then I would need to bind every time I switch - which is often | 20:38 |
| garyvdm | I'll check out :master | 20:38 |
| garyvdm | :bound works - thats very cool | 20:39 |
| knittl | hi! is there a way to stash commits like in git? | 20:45 |
| bob2 | shelve | 20:45 |
| knittl | bzr shelve? i can't find it in the manpage | 20:46 |
| knittl | and it doesn't work … (binary files) | 20:47 |
| lifeless | knittl: in used to be in a plugin, it recently got moved to core and fixed for binary files | 20:51 |
| LarstiQ | knittl: which shelve is this with btw, shelf1 or `shelve` from 1.10 and up? | 20:52 |
| lifeless | knittl: what bzr version do you have? | 20:52 |
| LarstiQ | knittl: hi, btw :) | 20:52 |
| knittl | hi LarstiQ :) | 20:52 |
| knittl | 1.6.1 i got on my machine | 20:52 |
| knittl | LarstiQ: i checked out blender (took hours) | 20:52 |
| LarstiQ | knittl: got everything though? | 20:53 |
| knittl | yup, i'm not missing a thing (till yet) | 20:53 |
| knittl | -yet +now … sounds better xD | 20:54 |
| knittl | ok, i just bzr rm --keep the files, committed my changes and pulled | 20:54 |
| knittl | weirdly enough it told me there was nothing to pull/merge, but before committing it told me there was a pending merge | 20:55 |
| lifeless | knittl: that means you had done a merge | 20:58 |
| knittl | lifeless: well, i didn't tell it to do a merge. but nevermind … i'm only doing a little branch for a sideproject xD | 20:58 |
| lifeless | knittl: check your bash history, I can pretty much guaranteed that 'bzr merge' is in there somewhere :) | 20:59 |
| knittl | yes, but it aborted and told it couldn't merge because of uncommitted changes | 20:59 |
| lifeless | knittl: it would do that after you'd made changes; such changes could have included an earlier attempt to merge | 21:00 |
| knittl | ok, i see :) | 21:00 |
| lifeless | one of the most obvious differences to git is that 'bzr merge' always waits for the user to commit the result - we don't autocommit | 21:00 |
| lifeless | -> breakfast | 21:02 |
| === fta_ is now known as fta | ||
| lifeless | Peng: btw, you should find bzr search lower on memory but not too much slower on indexing | 21:29 |
| Peng_ | lifeless: The new group_size stuff? Cool, how much lower? | 21:30 |
| * Peng_ fires up "bzr -Dmemory index". | 21:31 | |
| lifeless | a lot lower for mysql trees :P | 21:31 |
| lifeless | also loggerhead suggestions should be faster in format 2 search indices | 21:32 |
| Peng_ | Oh, cool. | 21:32 |
| Peng_ | Should suggestions in general be faster, or is it specific to LH? | 21:32 |
| lifeless | faster in general | 21:33 |
| Peng_ | Bah, the progress bar is already off the side of the screen. | 21:35 |
| lifeless | ugh | 21:35 |
| === kiko is now known as kiko-zzz | ||
| Peng_ | 9 minutes 14 seconds for bzr.dev. "VmPeak: 121356 kB" | 21:41 |
| Peng_ | That's awesome memory usage. It used to take decreasing the group_size to ~80 to do that. | 21:41 |
| jelmer | luke-jr, you can get the svn revno with "bzr log -r -1" | 21:45 |
| jelmer | luke-jr, "Fix released" means it's part of the main branch in the bzr world | 21:45 |
| jelmer | luke-jr, wrt svn-cp, there is no way to make that work while bzr can't represent that internally | 21:46 |
| Peng_ | Nice, "bzr search aye" returns an excerpt from doc/en/user-guide/images/workflows_pqm.png. At least it didn't confuse my shell. | 21:49 |
| jelmer | hi Peng_ | 21:51 |
| jelmer | Peng_, Did you get anywhere further with that bzr-svn+bzr-search issue you were seeing? | 21:51 |
| Peng_ | jelmer: I didn't try to. | 21:52 |
| luke-jr | jelmer: bzr doesn't have arbitrary metadata? | 21:54 |
| Peng_ | Haha, "bzr search branch" on bzr.dev sure has a lot of results. :) | 21:54 |
| luke-jr | jelmer: I'd rather not have to grep/sed on log -r -1 | 21:54 |
| jelmer | luke-jr: only revision properties, but they are set at commit time | 21:55 |
| jelmer | luke-jr, and the amount of work to work around the fact that bzr doesn't have copies makes me think we should really just implement copy support in bzr first | 21:56 |
| jelmer | luke-jr, sorry :-/ | 21:57 |
| Peng_ | "bzr search branch" had 5311 results. FYI. :P | 21:58 |
| * jelmer notices bzr-search is Peng_'s latest toy | 21:59 | |
| Peng_ | jelmer: Well, I go through a lot of toys. :P | 22:03 |
| luke-jr | jelmer: so implement copy support already :/ | 22:28 |
| luke-jr | jelmer: honestly, I'd benefit greatly from moving a number of my projects to bzr, but without copy support I can't :/ | 22:28 |
| knittl | is there a bzr move? | 22:28 |
| luke-jr | yes | 22:28 |
| jelmer | knittl, yes | 22:28 |
| knittl | it's not bzr mv … what is it? | 22:28 |
| luke-jr | knittl: it is | 22:29 |
| knittl | oh … i must've mistyped it then … | 22:29 |
| luke-jr | jelmer: supposedly the problem w/ copying is cherry-picking, but IMO copying is more important than cherry picking, so that problem should be deferred :/ | 22:30 |
| jelmer | luke-jr, fwiw, I agree with that (some copy is better than no copy) | 22:31 |
| jelmer | and just having the history stored now means we can use it later when there is proper merge support (if ever, as that's a very hard problem to solve) | 22:31 |
| knittl | can somebody help me with a concrete repo? (+branch) | 22:32 |
| knittl | i'm still more used to git … after all i'm a programmer and like it complicated xD | 22:33 |
| jelmer | knittl, what's the problem? | 22:33 |
| knittl | i can't get two directories pulled into b | 22:33 |
| knittl | * -b +my branch | 22:33 |
| Peng_ | jelmer: Hg supports merging across copies. | 22:34 |
| jelmer | Peng_: So what do they do when you copy a file and then merge in another branch that changes that file? | 22:35 |
| jelmer | Do you merge it into both copies ? Or just into one? | 22:35 |
| jelmer | If you base one source file on the other, you don't necessarily want the changes | 22:35 |
| Peng_ | jelmer: The other branch changed the original or the copy? | 22:35 |
| jelmer | The other branch changed the original | 22:35 |
| Peng_ | jelmer: The changes are merged into both. | 22:36 |
| Peng_ | Cue Peng_ being proved wrong. | 22:36 |
| lifeless | Peng_: 9 minutes is slower than usual to index though? | 22:40 |
| Peng_ | lifeless: I dunno. The group_size is 2000, and I'm not sure if I have numbers for that (and if I did, it would be for format 1). | 22:42 |
| Peng_ | lifeless: For group_size = 1000 from a couple months ago, it was 9m56s, so it's faster. | 22:42 |
| Peng_ | lifeless: So, I figure that if it is slower, it's not significant. | 22:42 |
| knittl | hm, how do i get those folders into my branch? :-/ | 22:45 |
| * Peng_ /aways | 22:46 | |
| lifeless | Peng_: thanks,c ool | 22:46 |
| jelmer | knittl, I'm not I understand completely what you're trying to do | 22:48 |
| jelmer | knittl, if you're trying to import folders, just "bzr add" followed by "bzr commit" should be sufficinet | 22:49 |
| knittl | jelmer: the folders already exist in the master branch | 22:49 |
| knittl | but they are 'unknown' in my branch | 22:49 |
| jelmer | knittl, so you want to do a cherry pick merge of those folders? | 22:49 |
| knittl | i just want to have them in my branch :D | 22:50 |
| lifeless | knittl: normaly you would just 'bzr merge master && bzr commit' to get something into your branch | 22:50 |
| knittl | i only tried bzr merge till now | 22:51 |
| knittl | it tells me there's »nothing to do« | 22:51 |
| lifeless | knittl: what is the *exact* command line you are running | 22:53 |
| ivazquez|laptop | Given a bzrlib.branch.BzrBranch6, how do I get the revision of a file within? | 22:53 |
| knittl | lifeless: bzr merge (master) | 22:53 |
| knittl | master or not, the output is the same | 22:54 |
| lifeless | ivazquez|laptop: you need a revision tree - so tree = branch.repository.revision_tree(branch.last_revision()); tree[tree.path2id('path')].revision | 22:54 |
| ivazquez|laptop | Excellent, thanks. | 22:55 |
| lifeless | knittl: the literal word master, or the URL ? | 22:55 |
| knittl | lifeless: ok, i tried "master" after your advice. but i tried the url before and it doesn't change anything | 22:56 |
| lifeless | knittl: does 'bzr missing URL' report anything? | 22:56 |
| knittl | »you have 4 extra revisions« + the logs | 22:58 |
| lifeless | knittl: ok, you have everything from that branch already; so either the folders you are talking about aren't versioned, or you've deleted them locally :) | 22:58 |
| lifeless | knittl: are you able to give us some more data? Is it an open source project that we could go peek at the url ? | 22:58 |
| knittl | i don't think i deleted them … | 22:58 |
| knittl | sure … lp:dnd or lp:~knittl/+junk/dnd | 22:59 |
| lifeless | I'm on a terrible wifi network at the moment, one second while I wait for my packets to get through :) | 23:01 |
| knittl | no problem … i'm glad you help me understand bzr a little | 23:01 |
| lifeless | https://code.edge.launchpad.net/~knittl/+junk/mtd ? | 23:01 |
| lifeless | I can't see a dnd branch of yours | 23:02 |
| ivazquez|laptop | Hrm. I'm getting "TypeError: unsubscriptable object" from tree[...]. | 23:02 |
| lifeless | ivazquez|laptop: oh sorry, tree.inventory[... | 23:02 |
| ivazquez|laptop | Ah, thanks. | 23:02 |
| knittl | lifeless: yes | 23:02 |
| lifeless | knittl: so is this your branch without the folders, or the branch with the folders that you want to get into your current copy? | 23:03 |
| knittl | it's my branch without the folders from dnd | 23:03 |
| knittl | they got added in r12, my r12 differs … | 23:03 |
| lifeless | ok | 23:04 |
| lifeless | and where is the dnd branch? | 23:04 |
| knittl | the dnd branch is just lp:dnd | 23:04 |
| knittl | or what do you mean? | 23:04 |
| lifeless | ok, got it. Now what are the folders you want? | 23:07 |
| knittl | Data/{Models,Sounds} | 23:08 |
| knittl | and i didn't remove them … i looked at my history | 23:09 |
| lifeless | your rev 15 merged his rev 12 that added the files, but your merge backed out his changes | 23:10 |
| lifeless | I imagine you did something like 'bzr revert .' and then committed something | 23:10 |
| lifeless | which will have kept the merge record but reverted all the code changes | 23:10 |
| lifeless | this is easy to fix | 23:11 |
| lifeless | are you still on rev 15? | 23:11 |
| knittl | iirc i did bzr rm --keep because they were changed (oh damnit …) | 23:11 |
| knittl | yup, i'm still on 15 | 23:11 |
| lifeless | ok, do a 'bzr st' and make sure there are no pending changes - no pending merges or changed files | 23:11 |
| knittl | no output—good :) | 23:11 |
| lifeless | now, 'bzr uncommit' and say yes when prompted. | 23:12 |
| lifeless | then do 'bzr shelve --all' | 23:12 |
| lifeless | you should now be on rev 14 | 23:13 |
| lifeless | do 'bzr st' again - is there any output | 23:13 |
| Peng_ | lifeless: Should "bzr search" use more memory when it finds tons of results? | 23:14 |
| knittl | ok, output after uncommit is added [my files] and 1 pending merge | 23:14 |
| knittl | bzr shelve --all | 23:14 |
| Peng_ | (Well, "more" = 88 MB, and "tons" = "5300") | 23:14 |
| luke-jr | jelmer: when multiple possibilities are valid, Conflict | 23:14 |
| lifeless | Peng_: probably, though that does seem excessive | 23:15 |
| lifeless | knittl: 'bzr st' output after doing the shelve ? | 23:15 |
| knittl | wops, that bzr shelve shoulda go into my shell xD | 23:15 |
| knittl | shelve won't complete | 23:15 |
| knittl | $ bzr shelve --all | 23:15 |
| knittl | bzr: ERROR: Changes involve binary files. | 23:15 |
| lifeless | odd | 23:15 |
| lifeless | what bzr version do you have? | 23:15 |
| knittl | 1.6.something | 23:16 |
| knittl | 1.6.1 | 23:16 |
| lifeless | ok, when you get a chance upgrade, cause that is fixed | 23:16 |
| knittl | that's the latest bazaar i get from the ubuntu repos | 23:16 |
| lifeless | for now though, just take a copy of your new files somewhere | 23:16 |
| Peng_ | https://launchpad.net/~bzr/+archive | 23:16 |
| knittl | okay | 23:17 |
| lifeless | knittl: when you've taken that copy, run 'bzr revert' | 23:17 |
| lifeless | knittl: and then 'bzr merge lp:dnd', if it merges without conflicts then do 'bzr commit' | 23:18 |
| knittl | ok, i'll try | 23:18 |
| knittl | ok, did that, worked fine :) | 23:18 |
| lifeless | put your files back, run 'bzr add' then 'bzr commit' | 23:19 |
| knittl | my files are still there … now just the regular bzr add? | 23:19 |
| knittl | great :) | 23:19 |
| knittl | why is this so complicated? :p | 23:19 |
| lifeless | well, its not normall :) | 23:20 |
| lifeless | knittl: also, you may like to know that you can push to lp:~knittl/dnd/mtd | 23:20 |
| knittl | :) | 23:20 |
| knittl | lifeless: yes, i know that …? | 23:20 |
| lifeless | cool (I just found it odd your branch was in +junk) | 23:21 |
| knittl | oh yes, i just wanted to test … maybe i'll move it to ~knittl/dnd later on | 23:21 |
| lifeless | you can do that in the web ui I think | 23:22 |
| lifeless | anyhow, http://bazaar-vcs.org/Download/ has newer versions of bzr for Ubuntu - just follow the link to the ppa | 23:22 |
| knittl | yes, but that's not important atm. is long as i can pull/push and have all data xD | 23:22 |
| knittl | $ bzr push | 23:24 |
| knittl | Using saved location: bzr+ssh://knittl@bazaar.launchpad.net/~knittl/%2Bjunk/mtd/ | 23:24 |
| knittl | bzr: ERROR: These branches have diverged. Try using "merge" and then "push". | 23:24 |
| knittl | :-$ | 23:24 |
| lifeless | add --overwrite | 23:25 |
| lifeless | that error is just a protection against mmistakes, but we redid that commit deliberately | 23:26 |
| knittl | ok, i really need to get a newer version | 23:26 |
| knittl | but that will hopefully be available in jaunty | 23:26 |
| knittl | lifeless: got it all back to normal. thanks! | 23:27 |
| knittl | i can always count on irc :) | 23:27 |
| Peng_ | "bzr search a" on bzr.dev takes 84 seconds (user time; realtime fluctuated), VmPeaks at 96 MB, and returns 12,429 results. :D | 23:30 |
| wgrant | jelmer: Is that add_records() fix in bzr.dev the one to stop it complaining about knit corruption? | 23:37 |
| jelmer | wgrant, it will stop a complaint if you run "bzr merge" | 23:38 |
| jelmer | wgrant, it won't affects "bzr check" | 23:38 |
| wgrant | jelmer: Right. Thanks for handling the bug quickly. | 23:38 |
| enigma1 | Hm...I just got an assert error with bzr-svn 0.5 | 23:39 |
| enigma1 | I was pushing a tag back up to SVN. | 23:39 |
| wgrant | jelmer: Is 0.5 stable now? | 23:39 |
| wgrant | I thought it was still unreleased. | 23:39 |
| enigma1 | AssertionError: Unable to find direct lhs parent for <RevisionMetadata for revision 9707, path cpp-common/tags/0.11 in repository 'daff2dd8-1c3d-0410-9cd2-f6297dd8f964'> | 23:40 |
| jelmer | wgrant: Yeah, it's not yet released (there's one rc out, another to follow soon) | 23:40 |
| enigma1 | No...this is off 0.5-trunk | 23:40 |
| === enigma1 is now known as enigma42 | ||
| jelmer | enigma42, Any chance you can try after removing the local cache? | 23:40 |
| jelmer | s/try/try again/ | 23:40 |
| jelmer | there was a bug similar to this fixed some days ago | 23:40 |
| enigma42 | jelmer: I'm a little nervous to clear the cache. | 23:41 |
| jelmer | enigma42: Why? | 23:41 |
| enigma42 | Last time I cleared the cache, my svn branches got out of sync with the SVN server. | 23:41 |
| enigma42 | So, the latest revisions in bzr were in svn, but they weren't correlated. | 23:41 |
| jelmer | enigma42: alternatively, you could just move it out of the way for now | 23:41 |
| enigma42 | True. | 23:42 |
| jelmer | just to see if it helps | 23:42 |
| enigma42 | OK...let me try. | 23:42 |
| enigma42 | Um...I think my 0.5-trunk my be a little of of date, do you know when the bug was fixed? | 23:42 |
| wgrant | jelmer: Is 0.5 in a PPA somewhere yet? | 23:42 |
| jelmer | wgrant, there's a month old package in debian experimental | 23:43 |
| jelmer | enigma42, I think about a week | 23:43 |
| * wgrant shall update that and PPA it. | 23:43 | |
| jelmer | enigma42, if removing your cache causes issues, that would be a sign there's a lot more wrong.. | 23:43 |
| enigma42 | jelmer: OK. So you think I should update to the latest 0.5-trunk, remove the cache, and try again? | 23:44 |
| jelmer | enigma42: Please do - that should tell us if those problems are still there, and allow us to fix them | 23:44 |
| enigma42 | OK. Let me give that a go. | 23:45 |
| enigma42 | Oh...on a different note, why is the bzrtools in the PPA *way* out of date? | 23:47 |
| enigma42 | Is that hard to build? | 23:48 |
| enigma42 | Is that something I could build and email to someone? | 23:48 |
| lifeless | Peng_: yes, thats not that useful :P - searching for multiple terms might be more useful :P | 23:49 |
| lifeless | jelmer: where is bzr-git up to? | 23:52 |
| lifeless | jelmer: [should the help be improved, is there meant to be a git:// urlspec?] | 23:52 |
| jelmer | lifeless: I'm making sure dulwich is ready for a release | 23:53 |
| jelmer | I blessed the current mapping as stable yesterday and renamed it appriopriately | 23:54 |
| jelmer | The idea is to release a simple bzr-git in a couple of days | 23:54 |
| jelmer | meanwhile I'm still working on optimization | 23:54 |
| enigma42 | jelmer: The most recent revision I'm seeing for the 0.5 tree is from Saturday, Dec 27. Does that sound right to you? | 23:55 |
| jelmer | lifeless, I was hoping to receive comments about my local branches spec, that's the main thing important about URLs | 23:55 |
| enigma42 | jelmer: I'm pulling from: http://people.samba.org/bzr/jelmer/bzr-svn/0.5/ | 23:55 |
| jelmer | enigma42, no, the most recent one is from a couple of hours ago | 23:55 |
| enigma42 | Ack...nevermind. | 23:55 |
| spiv | "[###################/] determining changes:analyzing repository layout:determining changes:copying revision:determining revisions to fetch:discovering revisions -2349/68866 | 23:56 |
| enigma42 | Looked at the wrong end of the log. :-P | 23:56 |
| lifeless | jelmer: I glanced at it | 23:56 |
| spiv | " | 23:56 |
| spiv | jelmer: that's an amusing progress line :) | 23:56 |
| jelmer | spiv: bug in the new progress code :-( | 23:56 |
| jelmer | spiv, btw, did you see my comments to your import patch? | 23:57 |
| spiv | jelmer: yeah, I did. | 23:57 |
| ivazquez|laptop | Taking a look at https://fedorahosted.org/packagedb/browser/0.3.x , how do I get 182 from the InventoryFile for AUTHORS? | 23:58 |
| jelmer | hmm, ohloh seems to've released the sourcecode related to their vcs analysis | 23:59 |
| lifeless | ivazquez|laptop: you map the revision back via the branch | 23:59 |
| jelmer | and added hg support | 23:59 |
| jelmer | unfortunately it's all ruby :-( | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!