| Keybuk | 1.0.0 | 00:01 |
|---|---|---|
| mindstorms | hi all and happy new year (to those celebrating it) | 00:01 |
| mindstorms | somebody mentioned a couple of weeks ago that he is working on creating a patched svn version | 00:02 |
| mindstorms | and a smarter install for Mac | 00:02 |
| mindstorms | any news on this? (I know there is a distro for 10.5, but the discussion was to make it available for Mac 10.4 too) | 00:02 |
| abentley | Keybuk: So in 1.0, the reason why it didn't support remote urls was that it always used working trees. | 00:03 |
| abentley | However, local URLs should work just fine. | 00:03 |
| abentley | In bzr.dev, diff has been reworked significantly, and now uses the last-committed-tree for remote URLs and for branches without trees. | 00:05 |
| === luks_ is now known as luks | ||
| zekel | Anyone know how to get svn style status? There seems to be a short keyword arg to status.show_tree_status that does what I want, but I'm having trouble getting started with the api. I'm not really sure if I want to be writing a script to filter the bzr output, call status from within, or make a plugin that is called by normal bzr st. Can someone point me in the right direction? | 00:39 |
| jelmer | zekel: bzr st -S ? | 00:39 |
| jelmer | what sort of thing you would want to use really depends on what you're trying to write | 00:40 |
| zekel | Oh, I guess I got confused. What I really want is the paths outputted to be relative to the cwd, and I took that to be the svn thing. | 00:40 |
| jelmer | and in what lnaguage | 00:40 |
| zekel | I was thinking python. | 00:40 |
| jelmer | ah, ok. I don't think there's a way to report paths relative to the cwd yet | 00:40 |
| jelmer | but I may be wrong | 00:40 |
| zekel | I think I asked if there was a builtin way and was told no, not yet. I find that I don't check in stuff as much if the paths are long, which is really bad. | 00:41 |
| zekel | I could do something with sed, but I thought I'd try to do it from within python instead. | 00:41 |
| zekel | I think what I need is to know the correct way to get a working tree object, so that I can call a status method, which I can then mess with. | 00:43 |
| lifeless | uhm | 00:43 |
| lifeless | just write a replacement formatter? | 00:43 |
| zekel | That sounds like a great idea. I should look at the normal one and make my changes? | 00:45 |
| lifeless | it may not be fully pluggable right now; a good place to start looking is bzrlib.status | 00:45 |
| zekel | That's why I'm thinking it might just be a better idea to have a filter script to pipe it through. | 00:47 |
| lifeless | perhaps | 00:51 |
| lifeless | we do like making things pluggable though :) | 00:51 |
| zekel | I can't say I'm an expert, so hacking bzrlib vs. filter script might be the difference between impossible and doable. | 00:52 |
| zekel | At least based on trying to read it. | 00:53 |
| lifeless | zekel: ah | 01:00 |
| lifeless | zekel: well, let me have a quick check | 01:00 |
| lifeless | look for 'if short:' in status.py | 01:01 |
| lifeless | see _mod_delta._ChangeReporter | 01:01 |
| lifeless | thats the interface you can use to write a new reporter | 01:01 |
| Peng | What exactly are rich roots? | 01:02 |
| lifeless | you can subclass that too | 01:02 |
| lifeless | and hardcode in a new class in status.py for now | 01:02 |
| lifeless | Peng: versioned '/' | 01:02 |
| Peng | What does that gain? | 01:02 |
| lifeless | bzr split; bzr join | 01:02 |
| Peng | How do rich roots help that? What information about directories is there? | 01:05 |
| lifeless | last-change and file-id | 01:06 |
| lifeless | (and children obviously) | 01:06 |
| Peng | Ok. | 01:06 |
| Peng | I still don't get it. | 01:06 |
| lifeless | it stops new files in the root of the project you joined being merged to the root of the combined tree, rather than the correct child node | 01:06 |
| lifeless | say you have project A: [/] and B: [/, /README] | 01:07 |
| lifeless | if you join B to A at subproject you get: | 01:07 |
| lifeless | A': [/, /subproject, /subproject/README] | 01:07 |
| lifeless | if you commit to B a new file 'configure' | 01:07 |
| lifeless | then merge B' to A' you want: | 01:07 |
| lifeless | A'':[/, /subproject, /subproject/configure, /subproject/README] | 01:08 |
| lifeless | this requires you to know that B''s '/' is A's '/subproject'. | 01:08 |
| lifeless | if B's / has no file-id then you can't tell that. | 01:09 |
| Peng | Ok. | 01:12 |
| Peng | That could be inferred, but I guess it would require rewriting history a bit? | 01:16 |
| Peng | Or, I dunno. | 01:16 |
| Peng | It sounds really easy to infer that when the merge is done, but I guess it doesn't map well to being stored? | 01:16 |
| lifeless | the only thing available to infer this is the presence of README | 01:17 |
| lifeless | or a deep history search | 01:17 |
| lifeless | the first fails if there is also another file, say AUTHORS, that became /AUTHORS rather than /subproject/AUTHORS | 01:18 |
| lifeless | though it is arguable at that point that a conflict should be raised (but you should still be clear about the options) | 01:18 |
| lifeless | and deep history searches are generally bad things to do | 01:18 |
| lifeless | because they break when you deliberately truncate history (e.g. partial branches because you don't want the deep history for now) | 01:19 |
| fullermd | Is there some reason other than backward compat not to go rich-root by default? | 01:21 |
| fullermd | It seems like most of the dangerous/surprising bits are segregated in the -subtree variant now. | 01:21 |
| lifeless | dunno; I'll think about that later. Coding now. Tchau. :) | 01:22 |
| fullermd | Better choice :) | 01:23 |
| lifeless | abentley: if you are pro the experimental format approach I put forward, consider a review :). | 01:49 |
| pfharlock | This is probably asked allot, but, I created a bzr branch and then tried to merge in something from a subversion repository and just can't seem to figure out how to get it to work. I have successfully branched a svn repo into a non-pre-existing bzr branch, but I was hoping to create a bzr repo and selectively merge in svn branches. I'm using the svn-bzr plugin. Any thoughts? Is what I'm trying to do even possible? I can give any det | 03:02 |
| pfharlock | ails that may be of help. | 03:02 |
| lifeless | well, an error message would be a good start :) | 03:06 |
| pfharlock | ok | 03:06 |
| pfharlock | one sec | 03:06 |
| * fullermd presumes it'll be a repo format issue. | 03:06 | |
| pfharlock | yes, that seems to be the case, here is the lead up | 03:07 |
| pfharlock | bzr init | 03:07 |
| pfharlock | bzr merge svn+file:///home/pfharlock/arc/subversion/snippets | 03:07 |
| pfharlock | bzr: ERROR: Repository KnitPackRepository('file:///home/pfharlock/test/.bzr/repository/') is not compatible with repository SvnRepository('file:///home/pfharlock/arc/subversion') | 03:07 |
| lifeless | upgrade --pack-0.92-rich-root I think is what you need | 03:09 |
| fullermd | Yeah. You'll need.... mmm... at least one of the rich-root formats, and maybe the -subtree one. Not sure how far bzr-svn pushes you currently. | 03:09 |
| Peng | --rich-root-pack | 03:09 |
| Peng | (no 0.92?) | 03:10 |
| pfharlock | ok, thanks for the advice, I'll try that, I'm on bzr 1.0 | 03:10 |
| Peng | bzr-svn is supposed to work with the rich-root formats. | 03:10 |
| pfharlock | just out of curiosity, why does the rich root format help? | 03:10 |
| lifeless | it adds metadata svn exports need to do the right thing with some of the copy-to-make-branch operations | 03:11 |
| pfharlock | yeah, that seemed to have worked, thankyou very much, will the rich root formats eventually become the default in bzr? | 03:15 |
| lifeless | yes | 03:16 |
| * igc lunch | 03:28 | |
| pfharlock | one more silly question, if you create a rich root format branch or repo, can you merge from it into a standard default knitpack or is it simply not backwards compatible that way? | 03:28 |
| abentley | pfharlock: It is not compatible for the same reason SvnRepository isn't compatible. There is data in "rich-root" formats that pack-0.92 cannot represent. | 03:35 |
| pfharlock | I see, thanks again for the help, it's really appreciated. | 03:36 |
| spiv | abentley: you replied to me, rather than the list | 05:39 |
| abentley | Oh, thanks. | 05:39 |
| spiv | abentley: I guess my habitual "group reply" in mutt that does "To: you / Cc: the list" breaks in combination with your reply habits? | 05:40 |
| abentley | I blame New Year's celebrations :-P | 05:40 |
| spiv | Heh. | 05:40 |
| abentley | I usually use "reply all", but I've recently changed my email address, so I've been a bit out of sorts. | 05:41 |
| abentley | spiv: Does that subtract_plans docstring look helpful? | 05:42 |
| spiv | abentley: very! | 05:42 |
| abentley | Oh, great. | 05:42 |
| abentley | I'm just applying your tweaks now. | 05:43 |
| === bigdog_ is now known as bigdog__ | ||
| === doko_ is now known as doko | ||
| igc | night all | 08:16 |
| mwhudson | lifeless: still here? | 08:56 |
| lifeless | fsvo here | 09:07 |
| lifeless | dinner is ready in 2 min | 09:07 |
| mwhudson | i was fighting getting tg installed on squid-cache | 09:07 |
| mwhudson | but now i'm on the phone to thumper | 09:08 |
| lifeless | tg is installed system wide | 09:13 |
| mwhudson | it is? | 09:15 |
| mwhudson | maybe i'm running things with the wrong python... | 09:16 |
| lifeless | 2.5 | 09:16 |
| mwhudson | ah yeah | 09:16 |
| mwhudson | lifeless: you're definitely special: http://www.squid-cache.org/bzrview/squid3/trunk/changes | 09:50 |
| mathrick | is there a plugin to support individual hunks commits, darcs style? | 10:07 |
| lifeless | mwhudson: did you put anything in a per-user python dir or something ? | 10:08 |
| lifeless | mwhudson: and how are you starting it ? | 10:08 |
| mwhudson | lifeless: "python2.5 ./start-loggerhead.py -f" | 10:17 |
| mathrick | how come the release notes (and actually releases thmeselves as well) are so irregularly linked from http://bazaar-vcs.org/news ? | 10:26 |
| mathrick | doesn't that happen automatically? | 10:26 |
| mathrick | urgh, for some reason "bzr branch http://michael.ellerman.id.au/bzr/plugins/diffstat/" takes about 2 minutes and heaps of bandwidth | 10:37 |
| mathrick | for all of 11 revisions | 10:37 |
| mathrick | even a simple bzr ls takes 20s | 10:38 |
| Peng | The remote repository contains a lot more. | 10:39 |
| Peng | (Probably a copy of bzr's branch.) | 10:41 |
| lifeless | mwhudson: I was using 'python start-loggerhead.py' | 10:54 |
| lifeless | Peng: bet that teh remote repository is knits ;) | 10:54 |
| Peng | lifeless: It is. | 10:54 |
| lifeless | mathrick: thats an old format repository | 10:54 |
| mathrick | ah | 10:55 |
| === cprov-out is now known as cprov | ||
| lifeless | night all | 10:55 |
| Peng | I wouldn't call it old, just not new. | 10:55 |
| Peng | G'night. | 10:56 |
| mwhudson | lifeless: ah ha | 10:57 |
| mwhudson | why the fuck does that make a difference | 10:57 |
| mathrick | Peng: it's slow enough to be old :) | 10:59 |
| mwhudson | lifeless: as predicted, though i'm not sure why, deleting the [logging] section of the config seems to help | 11:05 |
| mathrick | garh, how can I debug WHY a plugin can't be loaded? | 11:07 |
| mathrick | ie. get whatever error makes it so | 11:08 |
| Kinnison | Can someone point me at the docs for what a Text conflict is, vs. a Contents conflict? | 11:13 |
| mathrick | Kinnison: http://doc.bazaar-vcs.org/bzr.1.0/en/user-guide/index.html#conflicts-types | 11:15 |
| Kinnison | thanks | 11:16 |
| Kinnison | Contents conflict in vl.h | 11:17 |
| * Kinnison thinks bzr misclassified that file | 11:17 | |
| Kinnison | mmm or perhaps not | 11:22 |
| Kinnison | urgh | 11:22 |
| Kinnison | I think upstream deleted that file | 11:25 |
| Kinnison | pants | 11:25 |
| Kinnison | thanks | 11:25 |
| Kinnison | I hate qemu | 11:25 |
| mwhudson | mathrick: look in ~/.bzr.log | 11:26 |
| mathrick | mwhudson: aha, thanks | 11:33 |
| indu | how can i work out with trunk and branch methodology | 11:41 |
| mathrick | indu: eh? | 11:41 |
| mathrick | what do you mean? | 11:41 |
| indu | is there a specific way that a version control system should follow for publishing the source, to the community | 11:41 |
| indu | mathrick, i just started maintaining a version control system for my project, prev i had used svn | 11:42 |
| indu | now i am trying to shift to bzr which has much more better features | 11:43 |
| mathrick | indu: aha, there's no One True Way | 11:43 |
| indu | but I am confused how to organise it | 11:43 |
| mathrick | there are many ways, depending on what your project needs | 11:43 |
| indu | mathrick, my project has different releases, named as sethu, tarang, and anant | 11:43 |
| mathrick | indu: how big is it? How many core developers do you have? Is it open source? Proprietary? Proprietary with external contributors? | 11:44 |
| indu | its an opensource | 11:44 |
| indu | mathrick, and in future i will have some more release, | 11:44 |
| indu | thus, if I consider each as seperate repo, and then upload my souce as branches ( each repo has more than one branch) | 11:45 |
| mathrick | indu: what are those releases? Are they versions, or separate codebases? Do you need to maintain each independently, or does one release make others obsolete? | 11:47 |
| indu | mathrick, they are not versions, they are different releases | 11:47 |
| mathrick | but what is a release? | 11:47 |
| mathrick | are they separate programmes? | 11:48 |
| indu | mathrick, i am working on a linux distribution, | 11:48 |
| indu | based on debian | 11:48 |
| mathrick | okay? | 11:48 |
| indu | and to maintain its source i am trying this | 11:48 |
| indu | you can have a look at http://packages.bosslinux.in/boss/pool/ | 11:49 |
| indu | where there are three releases, and under each there is a main folder, and the source under that folder only need to be made version controlled | 11:49 |
| mathrick | aha, so they are effectively versions, except that they bundle a lot of things together each | 11:50 |
| mathrick | indu: is the source you want versioned related between releases (I assume yes)? | 11:51 |
| indu | no its not versined between releases, | 11:51 |
| indu | the source is independent for all the releases | 11:52 |
| mathrick | okay | 11:52 |
| mathrick | indu: so as far as you're concerned, sethu and tarang have no relationship at all? | 11:52 |
| indu | mathrick, yes | 11:53 |
| indu | mathrick, they are just under the project of our linux distro, but internally they are not related | 11:53 |
| mathrick | indu: then it makes sense to set up a separate repo for each of them | 11:53 |
| mathrick | indu: what is the structure of your team? Do you have any external contributors? How many internal ones do you have? | 11:54 |
| indu | internal are 15, and external may extend to 100 | 11:55 |
| indu | or more than that | 11:56 |
| mathrick | okay, so you might want to set up a PQM for the internal ones, and pull from independent repos for external ones, if they are less active than internals. Otherwise you could grant access for the active external ones as well | 11:57 |
| mathrick | PQM lets you set up things such as buildbots and automated testsuites easily | 11:57 |
| indu | what is PQM ? first time i am hearing this terminalogy | 12:00 |
| indu | mathrick, mathrick, one more thing, i also need a good gui for the users to easily view the structure so that they can download the source, if i use loggerhead, then each repo appears extended by default and thus my page in browser looks very big with sethu (80 branches under it) lll'ly tarang and anant | 12:00 |
| mathrick | indu: https://launchpad.net/pqm http://bazaar-vcs.org/Workflows | 12:01 |
| mathrick | indu: a lot is explained in http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html and http://bazaar-vcs.org/BzrPlugins | 12:03 |
| mathrick | including GUIs | 12:03 |
| mathrick | unrelated, could someone review this patch: http://pastebin.com/m22468f01 | 12:04 |
| mathrick | is this the right thing to remove diff_cmd_helper? | 12:04 |
| indu | mathrick, ok i will have a look at those docs, | 12:05 |
| mathrick | it irks me somewhat I had to recreate spec_tree() from it | 12:05 |
| indu | mathrick, one more small doubt | 12:05 |
| indu | mathrick, i am unable to configure bazaar with apache | 12:05 |
| indu | do u have idea on it? | 12:05 |
| mathrick | indu: I don't know what you mean by configuring bazaar with apache, so no | 12:06 |
| mathrick | and I have no idea about anything that involves the two together, so I'm unlikely to help | 12:06 |
| indu | mathrick, ok. thanks for the help provided | 12:09 |
| mathrick | no problem | 12:09 |
| mathrick | any comments on the patch? | 12:13 |
| Peng | mathrick: What's that a patch too? Also, use bundles (bzr send -o foo.patch) when submitting patches so your commits won't be lost. | 12:33 |
| mathrick | Peng: it's for diffstat plugin | 12:34 |
| Peng | mathrick: Oh. | 12:34 |
| mathrick | and I know about bundles, I just wanted someone to look at the code | 12:34 |
| Peng | Ok. | 12:34 |
| Peng | I don't know anything, so I have no comment on the code. | 12:35 |
| mathrick | ok | 12:35 |
| mathrick | ah, right, I've fixed a buglet since I pasted it | 12:35 |
| indu | mathrick, i want to use http protocol, for publishing the content | 12:41 |
| indu | mathrick, that can be done by configuring apache web server for bazaar, is it right? or any other way is available | 12:42 |
| mathrick | indu: then you just publish the directories, bzr repos are simple directories on disk | 12:42 |
| mathrick | there's no configuring of apache for bazaar | 12:42 |
| mathrick | indu: unless you mean a sophisticated repo viewer, a'la loggerhead | 12:43 |
| indu | mathrick, yes, my problem is solved now, many thanx | 12:52 |
| indu | could some one tell me, what this message mean http://rafb.net/p/yfdEH296.html | 13:07 |
| soren | indu: You can't push over http. | 13:08 |
| indu | I soren branch on http worked | 13:09 |
| soren | Yes? | 13:09 |
| soren | That's a read only operation. | 13:09 |
| soren | push means that you want to send you changes somewhere. You can't do that over http. | 13:09 |
| indu | soren, ok fine | 13:10 |
| indu | soren, then i changed my command to bzr push /usr/local/boss-bazaar/Anant | 13:13 |
| indu | and the o/p was created one branch, but where does it create? since its not available under /usr/local | 13:13 |
| indu | under /usr/local/boss-bazaar/Anant | 13:14 |
| soren | o/p ? | 13:14 |
| === Keltia__ is now known as Keltia | ||
| indu | o/p = output | 13:15 |
| soren | "the output was created one branch"? I don't understand, I'm afraid. | 13:17 |
| indu | in svn, to create a new project repo, we using svn import command to add files to the repository | 13:18 |
| indu | but its not possible in bzzr | 13:18 |
| soren | Ok, now I'm seriously confused. | 13:21 |
| soren | What is your question? | 13:21 |
| soren | If you want to start to use bzr, you issue "bzr init", add your files, bzr add them, and bzr commit them. | 13:22 |
| Peng | (Even better, you convert from your svn repo so you don't lose your history...) | 13:22 |
| dlee | Indu: When you bzr push, bzr get, etc., yes, you get one "branch" (the term "branch" has slightly different meanings in svn and bzr though, and I'm temporarily blurring the distinction). The "output" will go where you told it to; for example, "bzr push /usr/local/out" would create a directory called /usr/local/out and under it /usr/local/out/.bzr, in which the data for the branch would go. I'm not sure how much I'm helping here, but I | 13:45 |
| mathrick | pack-0.92 is the latest-and-fastest format? | 13:46 |
| dlee | Latest non-experimental format yes. I'll let someone else tackle the "fastest" part. There's a newer format, but I understand it's still experimental. | 13:47 |
| Peng | mathrick: Yes. It's a lot slower for operations that read the entire history (like log) though (which is being worked on). Also, older formats cache all of the information "bzr annotate" uses, but packs don't, so that's slower too. (There's going to be an annotation cache in the future.) | 13:50 |
| mathrick | okay, I was playing with a simple benchmark, and it seems that bzr rm on new files is pathologically slow | 13:51 |
| mathrick | I'm doing it on ~30K newly added files | 13:51 |
| Peng | mathrick: (On the flipside, operations that only read part of the history are much faster. So is dumb server network access. It also makes read-write dumb servers easier because files are not modified, only added and deleted.) | 13:52 |
| Peng | mathrick: Nice. | 13:52 |
| mathrick | and it has runtime at least 3m | 13:52 |
| Peng | Crapcrapcrap. | 13:53 |
| * Peng notes that running 'touch' 30,000 times isn't very fast either. | 13:53 | |
| Peng | Crapcrapcrap. Ran it in the wrong directory. | 13:53 |
| * Peng kills it after 17,000 files. | 13:54 | |
| mathrick | Peng: dunno, git can add all of them in 2s :) | 13:54 |
| dato | % seq -f %g.txt 30000 | =time -p xargs touch | 13:55 |
| dato | real 2.08 | 13:55 |
| dato | Peng: ^ | 13:55 |
| dato | Peng: the trick is not starting a new touch process per file ;) | 13:55 |
| mathrick | what's =? | 13:56 |
| mathrick | is that csh or some other abomination? | 13:56 |
| dato | zsh | 13:56 |
| dato | =time -> /usr/bin/time; I use in order not to use the shell builtin time, which I don't like | 13:56 |
| mathrick | oh | 13:57 |
| mathrick | someone should tell /usr/bin/time about spaces | 13:58 |
| Peng | dato: I know. | 13:58 |
| dato | mathrick: I like it with -p better | 13:58 |
| mathrick | bzr rm still running... | 13:58 |
| * Peng blows up his file manager moving all of the files with python. | 13:58 | |
| mathrick | dato: ah, that's basically what bash's builtin time does :) | 13:59 |
| dato | ah, oh :) | 13:59 |
| Peng | I've been meaning to check out zsh instead of bash. | 13:59 |
| Peng | Sigh. | 14:01 |
| mathrick | guess what, it's still running | 14:01 |
| Peng | I think I really did freeze my file manager. | 14:01 |
| mwhudson | command-not-found --> bash wins | 14:01 |
| mathrick | God, I hope it has runtime <= 30 mins | 14:02 |
| Peng | Oh nice. | 14:02 |
| mathrick | I might add it pegs the CPU while it's running, too | 14:02 |
| Peng | ps says it's using 0.1% of the CPU. top says it's using 99.9%. | 14:02 |
| mathrick | so there's definitely something wrong going on | 14:02 |
| Peng | mathrick: Don't kill it! It's running Folding@home! | 14:03 |
| mathrick | Peng: more like Removing@tmp | 14:03 |
| Peng | That still helps solve cancer, right? | 14:04 |
| mathrick | I don't think it does | 14:04 |
| Peng | Hopefully Konqueror will be faster than bzr. | 14:04 |
| mathrick | heh | 14:04 |
| Peng | Craap. | 14:04 |
| mathrick | Peng: y'know, if it does something exponential, it probably won't finish within my lifetime | 14:05 |
| mathrick | even just O(n^2) is pretty bad on n = 30K | 14:05 |
| Peng | Yay, Konqueror is done! | 14:07 |
| mathrick | okay, 20 mins, I'll kill it now | 14:11 |
| mathrick | okay, I've tracked the problem | 14:17 |
| mathrick | it's collecting the info about files | 14:18 |
| mathrick | since all are new and can't be safely removed, "bzr rm" will error out | 14:18 |
| mathrick | and some kind of info it's gathering there is taking forever | 14:18 |
| mathrick | if I add --keep, it's fast | 14:18 |
| mathrick | no --keep == exponential | 14:18 |
| === cprov is now known as cprov-lunch | ||
| statik | is it possible to create my own location aliases similar to the lp: prefix for branches? so that instead of always getting a new branch by typing 'bzr branch bzr+ssh://foo.host.com/code/branchname' I could just type 'bzr branch me:branchname ? | 14:58 |
| dlee | Statik: The Bookmarks plugin might be what you want: bzr branch bm:branchname should become possible with that. | 15:02 |
| statik | dlee: cool, thanks! | 15:03 |
| CardinalFang | Is this the right place to talk about bzr-gtk? | 15:22 |
| CardinalFang | I use the per-file commit comments, so there can be a lot of data. I wish that there were a "cancel, but retain comments" option in "bzr gcommit". Also, if I just "bzr uncommit", it would be nice if the previous comments were default in the UI for the next commit. | 15:25 |
| === cfbolz_ is now known as cfbolz | ||
| schierbeck | CardinalFang: yeah, this is the place | 15:28 |
| schierbeck | I'm not quite sure I follow -- you want to cancel the commit, but still retain the per-file commit messages for the next commit? | 15:29 |
| schierbeck | I guess it's possible, although we'd need to store the messages somewhere. | 15:29 |
| CardinalFang | schierbeck, Yes, that's what I meant. And when we uncommit, store those messages in the same place also. | 15:30 |
| Peng | When you uncommit, the revision is not removed from the repository. You could store the revision ID somewhere and use it to get the message. | 15:31 |
| CardinalFang | Ah, good to know. | 15:31 |
| schierbeck | Peng: yeah, we could do that... but to be honest, this stuff should go into bzr itself, or maybe a plugin | 15:32 |
| schierbeck | It's a somewhat different work model | 15:32 |
| schierbeck | Writing per-file messages on the fly, and then committing after a while | 15:33 |
| schierbeck | But yeah, a temporary solution would be to store the revision id, and clean it up after a completed commit | 15:34 |
| schierbeck | I'll have a look at it now | 15:34 |
| CardinalFang | schierbeck, I think we should capture the global commit message also. All the state of gcommit saved and reloaded. | 15:35 |
| schierbeck | CardinalFang: yeah, but I think the easiest way to get started is to restore the commit messages after an uncommit | 15:36 |
| schierbeck | later on I'll figure out how best to do it with cancelled commits -- perhaps write them to the repository anyway, and save the revid | 15:36 |
| schierbeck | Holy crap | 15:43 |
| schierbeck | I've never looked inside commit.py before | 15:44 |
| schierbeck | We actually implement just about everything ourselves | 15:44 |
| schierbeck | That stuff really needs to be moved to bzrlib | 15:44 |
| schierbeck | CardinalFang: this'll need more work than I anticipated... could I get you to file a bug report? That way it'll be easier to keep track of the issues | 15:46 |
| CardinalFang | schierbeck, Sure. | 15:46 |
| schierbeck | Thanks | 15:46 |
| CardinalFang | No, thank you. | 15:47 |
| schierbeck | :) | 15:47 |
| ubotu | New bug: #180107 in bzr "`bzr ls` should gain --modified and --added?" [Undecided,New] https://launchpad.net/bugs/180107 | 15:56 |
| mathrick | my bash completion for bzr broke :( | 16:02 |
| ubotu | New bug: #180109 in bzr "gcommit should load default comments (from "bzr uncommit" and UI button "cancel but retain")" [Undecided,New] https://launchpad.net/bugs/180109 | 16:05 |
| CardinalFang | schierbeck, ^ | 16:05 |
| schierbeck | CardinalFang: got it! :) | 16:06 |
| statik | dlee: I've got a patch for the bookmark plugin to list the stored bookmarks. Should I send it to you, or luks? | 16:12 |
| dato | statik: hm, different to what `bzr bookmarks` does? :) | 16:14 |
| statik | dato: now, how did I miss that :( | 16:14 |
| statik | hmm, this might be polished still | 16:15 |
| statik | I think the bookmark name should be listed first | 16:15 |
| dato | it is, at least here? | 16:15 |
| statik | I get the path, then the short name | 16:16 |
| statik | it looks like the code is intending it to print the other way | 16:16 |
| statik | so, I still have a patch, it's just shorter :) | 16:17 |
| * statik should learn to read more carefully | 16:17 | |
| Peng | That bookmarks plugin is cool. | 16:18 |
| dato | statik: maybe you should double check with an unmodified plugin, I still see the plugin name first? | 16:18 |
| Peng | That was something I liked from hg. | 16:18 |
| dato | (but I only have 1 bookmark, so it may be that) | 16:18 |
| statik | dato: this isn't about the plugin name. its about what is output when I run bzr bookmarks | 16:19 |
| statik | this fixes it | 16:19 |
| statik | - for name, url in sorted(bookmarks): | 16:19 |
| statik | + for url, name in sorted(bookmarks): | 16:19 |
| dato | statik: | 16:19 |
| dato | % bzr bookmarks | 16:19 |
| dato | forja svn+https://forja.rediris.es/svn/csl2-minirok/trunk | 16:19 |
| dato | (err, s/plugin name/name/ in my line above, sorry) | 16:20 |
| statik | dato: I see. it prints the opposite way in revno 3 from http://bazaar.launchpad.net/~luks/%2Bjunk/bzr-bookmarks/ | 16:21 |
| statik | dato: what revno do you have? | 16:21 |
| dato | I had 2, and pulled to 3 | 16:21 |
| statik | dato: then the only explanation is that I stored the data wrong when I first added a bookmark. | 16:22 |
| statik | and this whole thing has been me being confused | 16:23 |
| dato | makes sense | 16:23 |
| dato | from ~/.bazaar/bazaar.conf: | 16:23 |
| dato | [BOOKMARKS] | 16:23 |
| dato | forja = svn+https://forja.rediris.es/svn/csl2-minirok/trunk | 16:23 |
| statik | yep, I have my bookmarks inside out | 16:23 |
| ubotu | New bug: #180116 in bzr "bzr rm pathologically slow with new files and no --keep" [Undecided,New] https://launchpad.net/bugs/180116 | 16:26 |
| dato | jelmer: ping | 16:38 |
| jelmer | dato: pong | 16:38 |
| dato | jelmer: trouble in bzr-svn paradise ;) | 16:38 |
| dato | I have minirok.dev, which I push to svn+https://....../trunk | 16:39 |
| mathrick | funny, I just discovered bookmarks plugin today | 16:39 |
| dato | and I did svn mkdir https://..../branches; svn cp https://..../trunk https://...../branches/foo | 16:39 |
| dato | and b get minirok.dev minirok.foo | 16:39 |
| dato | but pushing from minirok.foo to svn+https://..../branches/foo won't work, is that expected? | 16:40 |
| jelmer | dato: What error do you get? | 16:40 |
| dato | bzr: ERROR: These branches have diverged. Try using "merge" and then "push". | 16:40 |
| jelmer | what does "bzr missing" say? | 16:40 |
| dato | AssertionError: Empty parent added, but child wasn't added !? | 16:41 |
| mwhudson | oo-oo | 16:41 |
| jelmer | uhm, ok | 16:42 |
| jelmer | that's definitely a bug | 16:42 |
| jelmer | what version bzr-svn is this? | 16:42 |
| dato | % cd .bazaar/plugins/svn && b revno | 16:42 |
| dato | 826 | 16:42 |
| dato | shall I pull? | 16:43 |
| jelmer | Hmm, I don't think anything has changed since that could've fixed it. | 16:43 |
| jelmer | Any chance you can file a bug? Links to minirok.dev, minirok.foo and the svn repository would be very useful | 16:44 |
| dato | ok. in the meantime, I guess it's ok if I continue to commit in minirok.foo? | 16:45 |
| jelmer | yep | 16:45 |
| dlee | I doubt we have this yet, but ... Do we have anything for handling line ending conversions? I just cvs-imported a 760+ revision CVS project that had been managed under Windows, but bzr co's now check out with LF, not CR+LF. I did the co under Window+Cygwin, then another one under just Windows using the stand-alone Windows binary bzr. | 16:57 |
| * dlee wishes everything including Windows could just use LF and be done with it :P | 16:58 | |
| mathrick | I still don't understand why workingtree 3 uses so much bandwidth | 17:01 |
| CardinalFang | It's dangerous to alter the data. Is that file with ordinals 13 and then 10 a text file or a PNG image? Oops, wrong choice. | 17:01 |
| dlee | CardinalFang: Yeah I know...otherwise I'd just ask for a co option to deal with it. Svn used properties because of that problem, and CVS used something like a checkin-time "property." I think line endings are on the ToDo list but not addressed yet; I'm mostly just verifying, while I try to figure out how to keep selling the Bazaar concept to my entirely Windows-based company that has been using CVS for about five years... | 17:04 |
| CardinalFang | dlee, Ah. We're in the same boat then. | 17:04 |
| mathrick | dlee: CVS had a horribly broken solution for that, though | 17:05 |
| mathrick | like for most things | 17:06 |
| dlee | hehehe | 17:06 |
| mathrick | given that more people seem to be awake now, anyone care to take a look at this patch: http://pastebin.com/m682e5b7e ? | 17:07 |
| mathrick | is this the correct way to remove diff_cmd_helper() use? | 17:07 |
| mathrick | I don't like the fact that I had to steal the whole spec_tree() from inside diff_cmd_helper() | 17:08 |
| dlee | It worked well enough for us, *if* people remembered the required -kb on cvs adds of non-text files. But that's a big *if* there. I liked the svn property idea better, but I used "native," which operated about like CVS anyway. (I did that to avoid having to put ^M at the end of every line when actually editing in an LF environment.) | 17:08 |
| dato | jelmer: bug #180128 | 17:15 |
| ubotu | Launchpad bug 180128 in bzr-svn "Cannot push to a branch `svn cp'ied`" [Undecided,New] https://launchpad.net/bugs/180128 | 17:15 |
| jelmer | thanks! | 17:15 |
| CardinalFang | I'm accustomed to creating a new branch that I expect to pull into several branches that never themselves merge. How does one create a branch that is the greatest common ancestor of two branches? | 17:16 |
| * mathrick doesn't really understand what CardinalFang said | 17:17 | |
| CardinalFang | (Well, "never" is wrong. One is a ostensibly a superset, but it may not have changes that have been added into the subset.) | 17:17 |
| CardinalFang | (Yet.) | 17:17 |
| dlee | CardinalFang: Verify this with more seasoned bzr users here, but I'd say bzr init-repo /path/proj, then cd /path/proj and bzr co projBranchThatWillAncestorNewOnes. To make a descendant, from /path/proj, bzr co ancestorBranchJustMade newBranchName. | 17:20 |
| CardinalFang | mathrick, Suppose I have a v1.0 branch and a v2.0 branch. I can't pull v1.0 to v2.0 because there are some things that others have added but are not yet added. I know I can add to v1.0 and cherry-pick "merge -c" just one new revision, but is there a way to create a branch that has only changesets that are in v1.0 and in v2.0, so I can add a changeset to it and pull into both with no trouble? | 17:20 |
| CardinalFang | ^not yet added^not yet merged to v2.0 | 17:21 |
| mathrick | CardinalFang: aha, first guess would be that bzr branch v1.0 common; bzr branch common v2.0 should work for you | 17:22 |
| CardinalFang | So, if a branch is a set of changesets, I want to create a branch that is the intersection of two other branches. | 17:22 |
| mathrick | if you want a commit applicable for both, push it into common, otherwise, into v1.0 or v2.0 as needed | 17:23 |
| dlee | Ah...I didn't know you had two already-existing branches; I thought you were doing this top-down (ancestor exists, then you spin off 1.0 and 2.0 from there). | 17:23 |
| mathrick | ah | 17:23 |
| mathrick | CardinalFang: what branches do you have *right now*? | 17:23 |
| mathrick | and how are they related? | 17:24 |
| CardinalFang | mathrick, One was created from another. v1 and v2. Most work is in v1, and people don't always merge to v2 soon enough. So, I can't pull from v1 to v2 without having to merge a bunch of stuff that I don't know anything about. | 17:25 |
| CardinalFang | So, i can't add to v1 and pull. Got it? | 17:25 |
| mathrick | aha, yes | 17:25 |
| CardinalFang | If I can create a branch that can always be pulled into v1 and v2, then I can fix my bug there and pull into both at once. | 17:26 |
| CardinalFang | Then, I don't have to care that other people were sloppy about getting their v1 changesets merged into v2. | 17:26 |
| mathrick | is v1.0 a strict superset of v2.0? | 17:27 |
| CardinalFang | No. It's a subet, in a perfect world, but in reality, there's a delay between when someone adds to v1 and when they pull to v2. | 17:27 |
| mathrick | aha | 17:28 |
| mathrick | I don't know if there's a tool to do what you want to do automatically | 17:28 |
| CardinalFang | I'm beginning to think that the answer is cherry-picking. | 17:28 |
| CardinalFang | Add rev12345 to v1 and then in v2, "bzr merge -c rev12345 ../v1" | 17:29 |
| mathrick | if one branch is reasonably close to the shared subset, you could branch the common off it, and then hack at it with rebase and selective uncommits until it looks like you want it to... I think | 17:29 |
| mathrick | CardinalFang: you have to be aware that cherry picks in bzr are *not* tracked right now | 17:30 |
| CardinalFang | Eeek! | 17:30 |
| dlee | You seem to want a justV1 place to commit, and a justV2 place, and a V1&V2 place. I don't think you'd need an ancestor branch; v1 and v2 are already related. This is a long shot into stuff I don't know so well, but would Rebase be of any use here? | 17:30 |
| mathrick | indeed | 17:30 |
| mathrick | dlee: I think rebase would be a tool towards building such a V1&V2 thing, but you need something to back out changes that should not be there | 17:31 |
| mathrick | I'm not sure how exactly you'd go about that, uncommit can't pull from the middle, and revert works on the text level, not revisions level | 17:31 |
| CardinalFang | mathrick, How about "merge -r big..small" to remove changesets? Is that safe? | 17:32 |
| mathrick | CardinalFang: what are big and small exactly? | 17:33 |
| dlee | I remember there was a CVS add-on (forget the name) for automating the commits to multiple branches for this type of problem. | 17:33 |
| mathrick | ahh | 17:33 |
| mathrick | CardinalFang: dunno, but now I think of it, bzr rebase --onto might do that whilst still preserving the history and identity of revisions | 17:34 |
| mathrick | unsure, the whole --onto thing is a bit magical | 17:34 |
| CardinalFang | Hrm. Time for some testing. | 17:34 |
| mathrick | but it will be manual, unfortunately | 17:35 |
| mathrick | CardinalFang: if you have enough crap to deal with, you might consider writing a plugin I guess | 17:35 |
| dlee | It occurs to me that this could probably also be handled by having multiple "parents" of one branch--i.e., commit in such a branch must clear more than one source branch before committing locally; but that also sounds like a mess to set up :) | 17:35 |
| mathrick | dlee: there was something called "multiparent" there in bzr.dev at one point, but it was completely undocumented and I have no idea what it really did | 17:36 |
| dlee | hehe | 17:36 |
| CardinalFang | Dang. The tool I'm accustomed to has a command that gives the greatest common ancestor between the current and a specified location on stdout. Then one can "clone -r`find-the-greatest-common-ancestor ../v1`" . Very useful, that. | 17:37 |
| mathrick | ahh, for that there's definitely support in bzrlib | 17:38 |
| mathrick | dunno about the UI | 17:38 |
| dlee | Mathrick: ...but I bet the bzrlib support only works on tracked stuff; cherrypicking would break that, no? I think you'd have to do text compares otherwise, to figure out what v1 changesets equal what v2 changesets. | 17:41 |
| mathrick | dlee: no, changesets have identity | 17:42 |
| CardinalFang | I'm not using cherry picking. I thought it was a solution to that problem, but now I don't. | 17:42 |
| dlee | Nice! I'm still figuring out the cherrypicking history issues; I guess they're not quite as bad as I thought. | 17:43 |
| mathrick | CardinalFang: I dunno how easy it is to produce a tree that's the intersection of A and B from bzrlib. But given it's the base of all merges, it should be doable | 17:43 |
| mathrick | dlee: ah, no, cherrypicking does break stuff | 17:43 |
| mathrick | but CardinalFang wasn't cherrypicking between V1 and V2 | 17:43 |
| * CardinalFang nods. | 17:43 | |
| mathrick | uh-huh, bzr rebase is quite dangerous | 17:45 |
| mathrick | it just went to happily destroy my test tree | 17:45 |
| mathrick | jelmer: poke? | 17:48 |
| dlee | New issue: I asked yesterday how to append one bzr repo to another. Motivation: trying to combine a CVS history for proj1 with an SVN history for later workk on the same proj1. Also, I want to rebuild a (so far unused) Bazaar repo that I initially built with Tailor but want to build with cvsps-import (to get tags), but there are subsequent bzr-only commits in it, so I'd have to cvs-import and then copy a stack of bzr commits on top of | 17:48 |
| mathrick | dlee: there was a graft plugin, but it's very much outdated | 17:49 |
| mathrick | I dunno if there's any successor to it | 17:49 |
| mathrick | I dunno if you can even get the source anymore | 17:49 |
| mathrick | dlee: http://spacepants.org/src/bzrgraft/ | 17:50 |
| dlee | thanks | 17:51 |
| mathrick | I wonder if I can make bzr shell make execute scripts | 17:56 |
| mathrick | wtf | 17:58 |
| mathrick | http://bazaar.launchpad.net/~bzr/bzr-dbus/trunk gives 404 | 17:58 |
| jelmer | mathrick, pong | 18:05 |
| jelmer | mathrick, even "bzr rebase-abort" doesn't restore it? | 18:06 |
| mathrick | jelmer: lemme see | 18:06 |
| mathrick | jelmer: it does some very scary things in any case | 18:07 |
| jelmer | mathrick: why? | 18:07 |
| mathrick | jelmer: and no, rebase-abort doesn't help | 18:07 |
| mathrick | sec, I'll give you a test case | 18:07 |
| jelmer | mathrick, what version of rebase are you using? | 18:08 |
| mathrick | lemme see | 18:13 |
| mathrick | jelmer: unsure, it's a lightweight checkout, I dunno how to check the latest revision in my working tree in this case | 18:15 |
| dlee | revno still works in lightweights | 18:15 |
| mathrick | dlee: but it reports the latest *upstream* revision | 18:17 |
| mathrick | at least it used to | 18:17 |
| mathrick | maybe that got fixed since 0.90 when I last tried | 18:17 |
| dlee | Oh hehehe, I've never lightweighted a branch someone else was committing to, so I'd never know | 18:17 |
| mathrick | I use it for plugins, since I have no real interest in having my own branch, really, I just need an up-to-date copy | 18:18 |
| dlee | I do wish I had a way to get the revno of my local branch after a revert though... | 18:18 |
| mathrick | dlee: you can't, since revert works on text | 18:19 |
| mathrick | I ran into the same thing myself | 18:19 |
| dlee | Darn! | 18:20 |
| dlee | I wonder if any VCS' support a sort of grep that returns all revisions / revision ranges containing matches to a regexp. Sounds really hard to do fast though, but I've often wanted that and never seen it offered. | 18:23 |
| dlee | I imagine it like grep, where instead of "filename:" at the beginning of each line, you'd have "revrange:" | 18:24 |
| dlee | actually revset, where a set could be one or more ranges, and a range could be a singleton | 18:24 |
| mathrick | bah, whole launchpad is broken | 18:24 |
| mathrick | you can't download things | 18:24 |
| mathrick | dlee: yes, there's a grep plugin for bzr I think | 18:24 |
| dlee | Uh oh, what'd I miss? * runs off to plugin page | 18:25 |
| mathrick | except that you won't get it, since launchpad is broken :( | 18:25 |
| jelmer | mathrick: Any chance you can report a bug about the rebase issue you just ran into with a testcase ? | 18:25 |
| * jelmer has been using rebase happily on a daily basis and knows of several other people who have | 18:26 | |
| mathrick | jelmer: yes, I'm just trying to determine what rev I have | 18:26 |
| mathrick | I also ran into bzr reconfigure butchering my lightweight checkout today, I need to investigate that | 18:27 |
| mathrick | jelmer: aha, so apparently I had r69, which is the latest | 18:32 |
| mathrick | now for a testcase | 18:32 |
| mathrick | jelmer: http://pastebin.com/f77fd13fb | 18:41 |
| mathrick | want me to write a bug report, or do you want to do it yourself? | 18:41 |
| jelmer | please file it | 18:44 |
| mathrick | okay | 18:44 |
| mathrick | done | 18:48 |
| mathrick | jelmer: is what I'm trying to do (ie. pretend that r3 happened immediately after r1, and there was no r2) sensible and supposed to work? | 18:48 |
| jelmer | the way I read it you're just trying to remove r3 | 18:50 |
| mathrick | jelmer: oh, then I'm misunderstanding something | 18:50 |
| jelmer | rebasing revision 2 on top of 1 | 18:50 |
| mathrick | jelmer: right, that's because -r -2 always confuses me by its changing semantics | 18:51 |
| jelmer | I don't think there are any changing semantics there.. | 18:52 |
| jelmer | the last revision (3) is -1 | 18:52 |
| jelmer | the previous-to-last (2) is -2 | 18:52 |
| mathrick | jelmer: well, yeah, but different commands interpret it slightly differently | 18:52 |
| jelmer | mathrick: Can you give an example? afaik we're consistent everywhere there | 18:53 |
| mathrick | jelmer: yes, in a repo with 3 revs, bzr diff -c -3 shows changes for revision | 18:54 |
| mathrick | *revision 1 | 18:54 |
| mathrick | however, diffstat -r -2 and -r -3 shows stats starting from the same revision | 18:55 |
| mathrick | which is revision 1 | 18:55 |
| jelmer | That makes perfect sense | 18:55 |
| mathrick | howso? | 18:55 |
| jelmer | well, not sure about diffstats behaviour | 18:56 |
| jelmer | but that's not a core bzr command | 18:56 |
| jelmer | but in a repository with 3 revisions -3 means revision 1 | 18:57 |
| mathrick | yes | 18:57 |
| mathrick | but -2 should mean r2 | 18:57 |
| jelmer | it does, for bzr diff | 18:57 |
| mathrick | I wonder where the inconsistency comes from in diffstat | 18:58 |
| jelmer | I think the fact that diffstat supports "-r2" is a bug in itself | 18:59 |
| mathrick | jelmer: anyway, why would rebasing r2 onto r1 kill r3? | 18:59 |
| mathrick | jelmer: oh? | 18:59 |
| mathrick | it should do the same thing as diff | 18:59 |
| jelmer | mathrick: It should accept -c2 or -r1..2 | 18:59 |
| jelmer | mathrick: sorry | 18:59 |
| jelmer | I forgot -r2 has meaning as well | 19:00 |
| jelmer | diffstat -r2 should report the changes between -r2 and the current working tree | 19:00 |
| mathrick | yes | 19:00 |
| mathrick | it does, except that it interprets -2 in an odd way | 19:00 |
| jelmer | that's a bug in a single plugin, you can hardly blame the rest of bzr for that.. | 19:01 |
| mathrick | it pretty much ignores the last rev | 19:01 |
| mathrick | jelmer: well, I know, it's consistent, just somewhat shifting conceptually depending on where you stand, not unlike the way how 1 is "different" in "asd"[:1] and "asd[1:] | 19:03 |
| mathrick | jelmer: in any case, why would rebasing r2 affect r3? | 19:03 |
| mathrick | jelmer: and I tried bzr rebase -r 3 --onto=1 . | 19:04 |
| mathrick | and it's a no-op | 19:04 |
| mathrick | I'd expected it to put r3 immediately after r1 in the history | 19:05 |
| jelmer | mathrick: because you're only rebasing a single revision | 19:05 |
| jelmer | I guess you may mean "-r2.." or something | 19:05 |
| mathrick | oh? | 19:05 |
| mathrick | jelmer: so, "rebase -r X --onto=Y" means "throw away everything that follows Y in history, and make it say X instead"? | 19:06 |
| mathrick | and if I say -r2 for X, it replaces the whole history with that single revision? | 19:07 |
| mathrick | jelmer: and why does it say "No revisions to rebase." when I do that> | 19:08 |
| mathrick | ? | 19:08 |
| jelmer | that's the bug | 19:08 |
| jelmer | it shouldn't abort early and print that error | 19:08 |
| mathrick | jelmer: ah, besides, that error message is missing a \n | 19:08 |
| jelmer | other than that, it looks fine | 19:08 |
| mathrick | jelmer: but then bzr rebase -r 3 --onto=1 . is buggy | 19:10 |
| jelmer | no, that makes sense | 19:12 |
| mathrick | then I'm not getting it | 19:12 |
| jelmer | -r3 means it will rebase the revisions up to r3 | 19:14 |
| jelmer | *up to and including | 19:14 |
| jelmer | -r1..3 means it will rebase revisions in that specific range | 19:14 |
| mathrick | urk | 19:15 |
| jelmer | ? | 19:15 |
| jelmer | also, using rebase on "." usually doesn't make any sense | 19:15 |
| mathrick | jelmer: see, that's why I said changing semantics :). Sometimes it means "up to and including X", sometimes it means "starting from X", and sometimes it means "exactly X" | 19:15 |
| mathrick | jelmer: I want to effectively remove r2 from the branch's history | 19:16 |
| jelmer | mathrick, I don't think that's confusing. It's the same way how merge works | 19:17 |
| jelmer | Perhaps you want something like "bzr rebase -r2..3 --onto 1 ." ? | 19:18 |
| jelmer | it may be necessary to run "bzr up" after that because of the bug you just reported | 19:18 |
| mathrick | jelmer: it doesn't appear to do anything | 19:20 |
| jelmer | and -r3..3? | 19:20 |
| mathrick | jelmer: it commits r2 and r3, but they end up in the same place they started in, so it's not a real change | 19:20 |
| mathrick | jelmer: that works, and results in a text conflict | 19:21 |
| jelmer | that's right | 19:21 |
| jelmer | since the delta for r3 won't apply cleanly on r1 | 19:21 |
| mathrick | yeah, I guessed that, since r3 modifies r2, which ceases to exist, it will give errors | 19:21 |
| mathrick | jelmer: will the revision identity be preserved afterwards? | 19:22 |
| jelmer | mathrick, the revision identity for r3 you mean? | 19:22 |
| mathrick | yes | 19:22 |
| jelmer | No the revid for that will change | 19:22 |
| jelmer | since it's parent revids have changed | 19:22 |
| jelmer | not changing that would be a severe bug | 19:22 |
| mathrick | jelmer: hmm, so it's not really suitable for tree surgery which would remove individual revs preserving the rest? | 19:23 |
| jelmer | mathrick: that's not really the use case for rebase.. you may want to have a look at 'bzr replay' (part of the rebase plugin) | 19:24 |
| jelmer | that basically just does diff+patch+commit with original metadata | 19:25 |
| mathrick | jelmer: aha, and the revisions will be seen as identical for purposes of calculating merges? | 19:27 |
| jelmer | no | 19:27 |
| jelmer | there's no way to do that | 19:27 |
| jelmer | rebase and replay will store metadata indicating what revisions they were originally based on | 19:28 |
| jelmer | however, they are not identical copies of those revisions and shouldn't be treated as such by merge. merge may be able to use that metadata in some way, but doesn't at the moment. | 19:29 |
| mathrick | jelmer: hmm, so there's no way of doing what CardinalFang wanted (ie. create a tree that only has changes common to A and B)? | 19:30 |
| mathrick | jelmer: "merge using that metadata in some way" would be tracking cherrypicks, right? | 19:30 |
| jelmer | basically, yes | 19:30 |
| mathrick | jelmer: so, if A and B share all revisions up to some revision R1, and afterwards there are revs that are sometimes in both, but sometimes only in one of them, the best you can do is split out the common tree up to R1, and there's no way to have a tree that would have the later commits that are present in both? | 19:34 |
| mathrick | though that seems wrong to me, my understanding would be that constructing such a tree is necessary for properly carrying out merges | 19:35 |
| jelmer | mathrick: how do you define "commits present in both"? | 19:40 |
| jelmer | commits with the same diff that have been applied to both trees? | 19:40 |
| mathrick | jelmer: sec, I'm drawing up a graph for that, and then we can ask CardinalFang if that's what he actually meant | 19:41 |
| jelmer | You could make those commits in a separate tree C and merge that into A and B | 19:41 |
| jelmer | where C could start out with R1 | 19:41 |
| lifeless | moin | 19:42 |
| jelmer | 'morning lifeless | 19:42 |
| CardinalFang | jelmer, The use case: You have two sister trees, neither of which is a subset of the other. You find a bug common to both and you want to fix it as easily as possible, without otherwise altering the sister trees. | 19:43 |
| jelmer | CardinalFang: that is the basic use case for cherry picks | 19:44 |
| mathrick | jelmer: but cherrypicks break merges | 19:45 |
| CardinalFang | Agreed, cherry picking would solve it. But that introduces other problems, yes? | 19:45 |
| fullermd | Well, or for daggy'ing it. | 19:45 |
| jelmer | mathrick: How do they break merges? | 19:45 |
| mathrick | jelmer: cherrypicks are not tracked, so they will introduce textual conflicts, no? | 19:45 |
| jelmer | merge treats cherrypick commits as ordinary commits at the moment | 19:45 |
| jelmer | mathrick: Merge will recognize the fact some revisions are cherrypicks, but from what I understand, CardinalFang is not merging between those trees anyway | 19:47 |
| mathrick | but I think he wants to at some point | 19:47 |
| CardinalFang | The SCM I use now, which is made by a notoriously litigious organization who shall not be named, provides a "repogca" command, which returns the "greatest common ancestor" of two trees, which one uses to branch off a tree that can be pulled into either. | 19:47 |
| mathrick | jelmer: will it recognise the fact they are present in the tree already? | 19:48 |
| jelmer | mathrick: No, that's what tracking cherrypick information is about. | 19:48 |
| mathrick | right, so merge does not really recognise cherrypicks | 19:48 |
| jelmer | CardinalFang: that would be possible with bazaar as well | 19:48 |
| CardinalFang | Yes, the two trees are constantly merged. But with more than a hundred people committing /all the time/, we can't sit on our hands if one person falls behind. | 19:48 |
| mathrick | CardinalFang: okay, so what kind of change can make V1 unmergeable into V2? | 19:49 |
| CardinalFang | Lack of knowledge. If there's a conflict in some dark corner of the code that only Joe and his acolytes know about, then I don't feel comfortable making decisions about what stays and what gets pruned away. | 19:50 |
| mathrick | CardinalFang: aha, and your current VCS can cope with that? Ie. track cherrypicks? | 19:51 |
| CardinalFang | No. Not at all. | 19:51 |
| CardinalFang | But it can give me a tree that has only common changesets in it. | 19:52 |
| mathrick | CardinalFang: uhh, but that's not very useful unless you can arrange for pulls that aren't contiguous wrt. to the source history (ie. cherrypicking) | 19:53 |
| mathrick | CardinalFang: let's sum up | 19:53 |
| fullermd | What he means is that there's a convenient command to set up a daggy fix. | 19:54 |
| * CardinalFang googles "daggy" | 19:54 | |
| mathrick | CardinalFang: google mercurial together with it | 19:55 |
| fullermd | There isn't one in bzr currently; you'd have to manually poke around 'missing' or something to find the GCA. | 19:55 |
| fullermd | monotone, actually. Nice page on their wiki. | 19:55 |
| mathrick | ahh | 19:55 |
| mathrick | CardinalFang: V1 is at R1, V2 is at R1'. At this point, V1 is cleanly mergeable into V2, right? | 19:55 |
| mathrick | CardinalFang: now there are two commits into V1, R2 and R3, and a commit R2' into V2. R2 conflicts with V2, but R3 doesn't. You want to pull R3 only, and leave R2 to be solved later, right? | 19:57 |
| jelmer | lifeless: any chance you can sponsor an upload of bzr-pqm to Debian? | 19:57 |
| mathrick | by "conflicts with V2" I mean "can't be merged into V2 without conflicts" | 19:57 |
| CardinalFang | mathrick, I'd rather not merge anything at all. I have an urgent bug to fix that is present in all trees. | 19:58 |
| CardinalFang | If I don't fix it in 20 minutes, the Sun explodes. | 19:58 |
| fullermd | Wait, let me get my camera. | 19:59 |
| CardinalFang | fullermd, You have at least another 8 minutes, from this distance. | 19:59 |
| mathrick | CardinalFang: okay, and how do you do that with your current tool (and what is that tool, if I may ask)? | 20:00 |
| fullermd | So what you want to do, is create a new branch from the LCA, and do the fix there, so it'll merge just fine into both sides. | 20:01 |
| CardinalFang | mathrick, With my current tool, I think it creates a tree that is only R1. I can create a new changeset R4 and pull that into V1 and V2 | 20:01 |
| mathrick | CardinalFang: aha | 20:02 |
| CardinalFang | fullermd, Yes. (Though I think it's "greatest" instead of "least", in the domain I'm thinking about.) | 20:02 |
| fullermd | I think it's usually expanded "latest" aroudn here. | 20:02 |
| CardinalFang | Ah. | 20:02 |
| fullermd | There's no command to give you it directly. The quickest way is probably 'missing', then pick the rev before the earliest in both lists. | 20:03 |
| CardinalFang | fullermd, Hmm. Perhaps I could write a plugin to do that. | 20:04 |
| fullermd | Probably. I don't think it would be terribly difficult. | 20:04 |
| fullermd | [3-way] merge already does it after all; you could just steal the code from there. | 20:05 |
| fullermd | May even be a function that does it you could just call and display. | 20:05 |
| mathrick | CardinalFang: if you had a parent, and at R0 V1, V2 and C were branched off it, then A had R1, C1 (merged from C), R2, and V2 had R1', C1, R2', would repogca create a tree that ends with R0, or would it have R0, C1? | 20:11 |
| CardinalFang | mathrick, Good question. I'll try it. | 20:11 |
| CardinalFang | fullermd, FWIW, graph.py says "least." :) | 20:14 |
| CardinalFang | Sorry, "lowest". | 20:14 |
| fullermd | We should declare once and for all that it stands for "lambada". | 20:21 |
| fullermd | It may not mean anything useful, but it should lead to some really fun questions. | 20:21 |
| mathrick | *lambda | 20:21 |
| mathrick | :> | 20:21 |
| fullermd | No, I meant lambada :p | 20:21 |
| CardinalFang | llama | 20:21 |
| fullermd | lambda is too close to actually meaningful. | 20:21 |
| mathrick | CardinalFang: anyway, if you write a plugin, it should be doable to get a tree that ends with R0, C1, since that's the tree merge has to construct when you say cd B; bzr merge A | 20:25 |
| lifeless | jelmer: good chance; this arvo probably | 20:30 |
| Arjen | Hi, is the benchmark script available somewhere? | 20:33 |
| mathrick | lifeless: can I trick you into looking at my short patch that removes diff_cmd_helper() use? | 20:33 |
| mathrick | I need someone with a clue if that's the way it's supposed to be done | 20:34 |
| lifeless | not now; coding. I'll come up for air when Lynne gets up probably. | 20:35 |
| lifeless | so in a couple of hours | 20:35 |
| mathrick | lifeless: okay then, I guess I'll just submit it upstream and wait for review there, I'll be sleeping in a couple of hours | 20:36 |
| mathrick | mathrick@hatsumi:/tmp/rebase$ bzr reconfigure --branch | 20:38 |
| mathrick | bzr: ERROR: Repository KnitRepository('file:///tmp/rebase/.bzr/repository/') is not compatible with repository KnitRepository('http://people.samba.org/bzr/jelmer/bzr-rebase/.bzr/repository/') | 20:38 |
| mathrick | huh? | 20:38 |
| jelmer | rebase is using dirstate-with-subtree | 20:39 |
| jelmer | looks that's confusing reconfigure | 20:39 |
| mathrick | it's a lightweight checkout which I converted from knitpack to knit (since it was erroring out about KnitPackRepository being incompatible) | 20:39 |
| mathrick | jelmer: oh | 20:39 |
| mathrick | the fact that reconfigure does not do a checkout is horribly confusing | 20:41 |
| mathrick | it looks as if it just ate your tree | 20:41 |
| lifeless | mathrick: I filed a bug last week on this; you might compare and see if its the same | 21:05 |
| ubotu | New bug: #180196 in bzr "bzr reconfigure gets confused by dirstate-with-subtree" [Undecided,New] https://launchpad.net/bugs/180196 | 21:06 |
| mathrick | lifeless: I can't find it, care to give a bug#? | 21:10 |
| ryanakca | why is it that when I go "bzr up" on a local (well, ssh'd to server) branch, I get the following error message? | 21:54 |
| ryanakca | Using saved location: http://bazaar.launchpad.net/~...../ | 21:54 |
| GoClick | Does bzr store all it's information is a million .bzr folders like svn? | 21:55 |
| ryanakca | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~...../.bzr/repository/lock): Transport operation not possible: http does not support mkdir() | 21:55 |
| mathrick | GoClick: ? | 21:55 |
| Odd_Bloke | GoClick: No. | 21:55 |
| mathrick | GoClick: you mean an .svn dir in ever subdir? | 21:55 |
| * ryanakca isn't uploading... so it shouldn't matter if http can or can't make a directory... | 21:55 | |
| mathrick | no | 21:55 |
| GoClick | mathrick: yeah | 21:56 |
| Odd_Bloke | GoClick: There is a single .bzr directory for your branch. | 21:56 |
| GoClick | good | 21:57 |
| * mathrick wonders if there's anything about SVN that's strictly better than bzr | 21:58 | |
| Odd_Bloke | mathrick: It's faster for a lot of things. :p | 21:58 |
| fullermd | Partial checkouts. | 21:58 |
| jelmer | mathrick: eol-conversion support, better performance for large binaries, cherrypick tracking, ... | 21:58 |
| mathrick | Odd_Bloke: by not doing things, that's like being really fast at writing to /dev/null | 21:58 |
| mathrick | jelmer: it tracks cherrypicks how? Last time I checked, SVN had no merge support | 21:59 |
| GoClick | We put a lot of binaries in our version control as is, will that be a problem? | 21:59 |
| fullermd | That means cherrypicks can't screw up merges ;) | 21:59 |
| foom | mathrick: but if you want to write to /dev/null, it sure would be nice if it went fast, instead of slow. | 22:00 |
| jelmer | mathrick: 1.5 has | 22:00 |
| jelmer | mathrick: svn has always had merge support, just hasn't had merge /tracking/ support until 1.5 | 22:00 |
| mathrick | foom: sure, but it's not a reason to say "my foo is better than yours, since it's really fast at writing to /dev/null, whereas yours takes a lot of time to write to screen" | 22:00 |
| mathrick | jelmer: aha, so you can finally merge branches in a sane way and it doesn't kick you in the nuts harder for doing it often? | 22:01 |
| jelmer | yup | 22:01 |
| jelmer | that's 1.5 only though, which was supposed to be released 2 years ago or something.. | 22:02 |
| foom | actually i think only 2 months ago or something | 22:02 |
| foom | but when i last skimmed the mailing list it didn't look too promising | 22:03 |
| foom | i'd sure like to be able to switch to bzr sometime soon. :) | 22:03 |
| mathrick | foom: not being punished for merging would be pretty promising in my book:) | 22:03 |
| jelmer | foom: They've always been pushing the deadline further forward | 22:03 |
| foom | mathrick: i mean, the chance of a release coming soon wasn't looking good | 22:03 |
| jelmer | foom: When I originally started on bzr-svn 1.5 was also "almost done" | 22:04 |
| jelmer | That's more than 2 years ago now | 22:04 |
| mathrick | foom: do like I do, use bzr-svn to manage your code, this way instead of putting up with stupid buggy SVN crap you will help bzr-svn maintainers discover new ways to improve their quality ;) | 22:04 |
| * mathrick runs | 22:04 | |
| fullermd | OTOH, you keep finding new bugs in the python bindings, so... :p | 22:04 |
| foom | mathrick: that's the plan, but bzr is too slow right now | 22:04 |
| mathrick | jelmer: so it's still not released? | 22:05 |
| mathrick | foom: only in the initial checkout, or do you mean something else too? | 22:05 |
| mathrick | the checkout thing is mucho painful because you can't horizon the history | 22:05 |
| jelmer | mathrick: svn 1.5 ? Nope, and doesn't look like it's going to be released soon either, at least not within the next couple of months. | 22:05 |
| foom | mathrick: log is excessively slow at the moment | 22:05 |
| mathrick | jelmer: oh, I see, I thought you were talking about actual shipped SVN now | 22:06 |
| === cprov is now known as cprov-away | ||
| lifeless | foom: local or remote. Please file a bug if it's remote, tagged hpss | 22:06 |
| foom | lifeless: local | 22:06 |
| mathrick | foom: dunno, it's being pretty fast for me, and I have repos with 3K revs with 2K-revs merges along the way | 22:06 |
| fullermd | log -v is downright vicious. | 22:06 |
| mathrick | lifeless: what does hpss mean? | 22:06 |
| foom | lifeless: i saw a bug already filed about log getting slow in pack format repos | 22:06 |
| lifeless | mathrick: smart server | 22:06 |
| mathrick | oh right, I didn't try it with pack yet | 22:07 |
| mathrick | lifeless: and hp? | 22:07 |
| mathrick | high perf? | 22:07 |
| lifeless | foom: there is a slow down | 22:07 |
| lifeless | mathrick: yes | 22:07 |
| lifeless | foom: but it should still be plenty fast; are you just doing 'bzr log' or -v or other optoins? | 22:07 |
| foom | lifeless: time bzr log -r30000 [waiting] | 22:08 |
| foom | real 0m35.296s | 22:08 |
| foom | user 0m28.513s | 22:08 |
| foom | sys 0m0.234s | 22:08 |
| foom | i'm sure if i was using a 3krev repo it'd be fine. | 22:10 |
| jelmer | 14k revs is 5 seconds here | 22:10 |
| lifeless | foom: using packs? | 22:10 |
| * mathrick wonders what git would score on that | 22:11 | |
| foom | lifeless: repository: Packs containing knits with rich root support | 22:11 |
| mathrick | it's awesomely fast to be sure | 22:11 |
| fullermd | -v will slaughter you even with 3k revs. | 22:11 |
| jelmer | yeah, -v is slow as hell | 22:11 |
| mathrick | OTOH, with bzr I'm able to figure how to un-add a file, with git, I'm not... | 22:11 |
| foom | 43276 revisions | 22:12 |
| foom | 599396 KiB | 22:12 |
| fullermd | With a ~1800 rev tree, 'log' runs in 1.7 seconds. -v has passed the 3 minute mark so far, and broken 120 meg of RAM usage (impressive, since .bzr/ is only ~16 meg) | 22:12 |
| fullermd | Oh, there it finished. 225.5 user seconds, half a second of system time. 3:48 wall. | 22:12 |
| lifeless | foom: how many packs do you have ? | 22:13 |
| lifeless | fullermd: -v will get better before too much longer, but its a disk change | 22:13 |
| foom | just count the files in .bzr/repository/packs? | 22:13 |
| foom | 24. | 22:13 |
| lifeless | foom: yeah, or cat .bzr/repository/pack-names | 22:14 |
| fullermd | lifeless: And one I look heartily forward to, especially if it lets me 'log' more than one file at a time too. | 22:14 |
| foom | it says 22 | 22:14 |
| lifeless | foom: you've had some interrupted uploads then | 22:14 |
| lifeless | do a ls -lS of the packs directory | 22:15 |
| lifeless | is there a good size distribution ? | 22:15 |
| lifeless | also you may find log gets faster if you do 'bzr pack' | 22:15 |
| ubotu | New bug: #180207 in bzr-eclipse "Creating project from bazaar branch" [Undecided,New] https://launchpad.net/bugs/180207 | 22:15 |
| ubotu | New bug: #180208 in bzr "commit failed because of lack of disk space but with unclear message" [Undecided,New] https://launchpad.net/bugs/180208 | 22:15 |
| foom | lifeless: yeah, bzr-svn crashed my machine while importing because it ran it out of ram. | 22:15 |
| foom | and the kernel OOM killer decided to kill everything *else* | 22:15 |
| lifeless | OOM FTW | 22:15 |
| jelmer | foom: That bug has been fixed since | 22:16 |
| jelmer | foom: http://subversion.tigris.org/issues/show_bug.cgi?id=3052 | 22:16 |
| foom | jelmer: yeah, i saw | 22:16 |
| mathrick | hmm, you can't uncommit a single revision in the middle, right? | 22:23 |
| thumper | mathrick: right | 22:26 |
| thumper | mathrick: it is my understanding that you uncommit the latest commit | 22:26 |
| mathrick | http://bazaar-vcs.org/BzrVsHg#head-b92d4fdb6541abcf14ea53686e4bccc9f7b6ffa5 seems to suggest that bzr can indeed do that | 22:27 |
| mathrick | or so I read it at least | 22:27 |
| foom | lifeless: anyhow, yes, there's a good distribution of sizes, the biggest is 245595344 and smallest is 1875 and there's lots in between. | 22:28 |
| foom | lifeless: after bzr pack, it is down to 4.421s | 22:28 |
| fullermd | I think that page is misleading; bzr uncommit is only very vaguely related to hg rollback. | 22:28 |
| fullermd | uncommit removes a rev (or more precisely, changes the head). rollback, AIUI, creates a new rev with opposite changes. It's more like bzr merge -rx..x-1 | 22:29 |
| foom | lifeless: still slow, but only 4x slower than svn instead of 30x. | 22:29 |
| mathrick | foom: that would be a bad distribution if they differ in sizes greatly | 22:30 |
| mathrick | I believe | 22:30 |
| lifeless | morning poolie | 22:35 |
| lifeless | mathrick: they are meant to differ geometrically | 22:36 |
| mathrick | ah | 22:36 |
| poolie | hi lifeless | 22:38 |
| lifeless | foom: ok; feel free to find out whats slow then ;) I don't feel like downloading a 1/2 GB repo to find out :] | 22:38 |
| igc | morning | 23:01 |
| lifeless | hi igc | 23:02 |
| igc | hi lifeless | 23:02 |
| foom | lifeless: is the 7x slowdown to be expected for 22 pack files vs 1, then? | 23:03 |
| lifeless | foom: pack orders the revision xml texts topologically | 23:06 |
| lifeless | foom: so you do ascending IO within the pack, which linux likes a lot. | 23:07 |
| foom | lifeless: sure but it's CPU time being spent. | 23:08 |
| lifeless | foom: possibly index layer stuff then, which is on the todo | 23:12 |
| ecasbas | hi, I am having a problem creating a local repository, the setup is like: http://wiki.squid-cache.org/Squid3VCS#head-a70c042fb73ac3863a0fd32ff452b59279ff7030 | 23:21 |
| ecasbas | at the momment of: bzr branch $TRUNKURL ~/squid-repo/trunk | 23:21 |
| ecasbas | I get: bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n' | 23:22 |
| ecasbas | Bazaar 0.90 / Ubuntu 7.10 | 23:22 |
| jelmer | ecasbas: you need a newer version of Bazaar | 23:23 |
| jelmer | at least 0.92 or higher | 23:23 |
| ecasbas | ok, thanks then I'll download the 1.0 | 23:23 |
| ecasbas | thanks jelmer | 23:23 |
| ecasbas | thanks very much, the 1.0 worked perfectly! | 23:29 |
| lifeless | perfect example of our clear format strings not being enough lol. | 23:34 |
| poolie | I suspect many "they change formats too often" complaints are really "the changes are too bumpy" | 23:40 |
| foom | that error seemed pretty clear to me, unlike the ones that say KnitRepository isn't compatible with KnitRepository or w/e. :) | 23:43 |
| fullermd | Well, the changes aren't all that bumpy (at least, they're reasonably close to the irreducible limit of bumpiness) | 23:46 |
| lifeless | poolie: I agree with your statement if you change 'too bumpy' to 'we talk about it' :) | 23:51 |
| fullermd | I know I've seen several bumps in mtn, and it just wouldn't do anything 'till I told it to upgrade. | 23:52 |
| fullermd | Going across bzr bumps works OK (well, repo changes are usually **SLOOOOW** to work across, but they work, and you can keep working locally without the upgrade) | 23:52 |
| jelmer | imho bzr upgrade is too slow, that's in fact the reason I haven't upgraded a lot of my branches yet | 23:53 |
| fullermd | A big bump is that inter-repo-format work is so slow that practically, upgrading that means you need to flag day _every_ branch of the project. | 23:55 |
| lifeless | jelmer: to packs ? | 23:58 |
| lifeless | jelmer: its the time to clone, no more. | 23:58 |
| jelmer | it's actually reconcile that was the most problematic | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!