| james_w | pickscrape: however, this gets pretty silly if upstream never commits anything and you just do update && commit --local over and over again | 00:00 |
|---|---|---|
| james_w | which is pretty silly in itself | 00:00 |
| james_w | pickscrape: I think this would be a worthy topic for discussion on the mailing list, are you subscribed? | 00:01 |
| pickscrape | Yes, you could end up with a really deep nest of what accounts to one merge | 00:01 |
| pickscrape | I'm already composing one :) | 00:01 |
| james_w | great! | 00:01 |
| jelmer | jml: 0.4.10 | 00:37 |
| jml | jelmer: thank you. | 00:38 |
| jml | jelmer: btw, I have tribunal using subunit now. | 00:38 |
| jml | (it was you who was asking, right?) | 00:38 |
| jelmer | yep | 00:39 |
| jelmer | I'll give that a try soon | 00:39 |
| jelmer | we're using subunit inside of samba 4 and it would be awesome to be able to use tribunal there | 00:40 |
| jelmer | lifeless: is there any news on your subunit patch for check? | 00:40 |
| jml | jelmer: it's still... rough | 00:41 |
| jml | jelmer: if I get more users than just "me sometimes", I promise I'll take better care of it. | 00:42 |
| jelmer | well, we're used to rough :-) | 00:45 |
| lifeless | jelmer: they want docbook and other crap written up | 00:45 |
| lifeless | jelmer: which is afaict a higher standard than the previous code; I've kind of lost interest | 00:45 |
| jelmer | lifeless: ah, ok | 00:46 |
| jelmer | lifeless, I may have a look at finishing it then | 00:46 |
| lifeless | that would be cool | 00:50 |
| mxpxpod | jelmer: ping? | 00:55 |
| jelmer | mxpxpod, pong | 00:57 |
| mxpxpod | jelmer: I'm getting a strange exception using bzr-svn 0.4.10 and bzr 1.5rc1 | 00:58 |
| mxpxpod | jelmer: trying to push some changes | 00:58 |
| mxpxpod | jelmer: do you want me to file a bug or look at it here? | 00:59 |
| jelmer | please file a bug | 00:59 |
| mxpxpod | k | 00:59 |
| mxpxpod | jelmer: #229775 | 01:04 |
| jelmer | mxpxpod, thans | 01:10 |
| jelmer | lifeless, hmm, upstream appears to be dead | 01:10 |
| lifeless | for check? | 01:10 |
| lifeless | its definitely dysfunctional IMO | 01:10 |
| jelmer | it's the only sane library of this sort for C though | 01:13 |
| === mwhudson__ is now known as mwhudson | ||
| lifeless | yup | 01:24 |
| lifeless | which is why I patched | 01:24 |
| === kiko is now known as kiko-zzz | ||
| Verterok | awilkins: pong (sorry for the delay) | 02:58 |
| lifeless | woo | 03:24 |
| lifeless | get_record_stream now behaving moderately sanely | 03:24 |
| lifeless | although not memory capped yet | 03:24 |
| ricardokirkner | hi. I don't know if this is the place to ask, but since it's related I'll just shoot: does anyone know the status of the trac-bzr project? is the dead - stable - or active? I ask because I want to start getting more into bzr and bzr-related development, and the trac-bzr project just scratches one of my itches :-) | 03:41 |
| mlh | ricardokirkner: I think it has stalled - people thought that trac wasn't a good git for bzr | 03:53 |
| mlh | good FIT | 03:53 |
| mlh | but don't take my opinion as anything remotely official | 03:54 |
| mlh | there's probably better alternatives (to trac) out there anyway | 03:54 |
| ricardokirkner | mlh, and what would that alternative be? | 04:04 |
| chandlerc | ricardokirkner: you can always push your bzr repository into a subversion one for the purposes of running trac | 04:04 |
| chandlerc | ricardokirkner: i do this for all of my OSS projects (code.google.com rather than trac, but same principle) | 04:04 |
| ricardokirkner | chandlerc, not really, since bzr-svn (which I guess you are suggesting) does depend on the subversion 1.5 python bindings which are not readily available on all linux distributions | 04:05 |
| chandlerc | yea, thats the price you pay | 04:05 |
| ricardokirkner | and my attempt is to make bzr adoption as low impact as possible | 04:05 |
| chandlerc | what linux distro? | 04:05 |
| ricardokirkner | fedora at work | 04:05 |
| chandlerc | ubuntu has patched subversion packages, and i thought fedora did as well | 04:05 |
| ricardokirkner | and thats something I cannot change | 04:05 |
| chandlerc | gentoo has them | 04:05 |
| ricardokirkner | no, fedora lacks behind a lot :-( | 04:05 |
| chandlerc | so its not as big of a price as switching to svn 1.5 | 04:05 |
| chandlerc | you *can* do it by installing the python bits in the users home directory, but yea, kinda ups the ante of moving to bzr | 04:06 |
| chandlerc | however, installing subversion python bindings is a *lot* easier than retrofitting vcs/project management tools like Trac, Retrospectiva, Collaboa, googlecode, sf.net, et al to use bzr | 04:06 |
| chandlerc | oh, ohloh support comes free as well | 04:07 |
| ricardokirkner | chandlerc, you mean I can install the python subversion 1.5 bindings in my home folder, without them interfering with the system subversion installation | 04:07 |
| ricardokirkner | and that way using bzr-svn? | 04:07 |
| chandlerc | yes | 04:07 |
| chandlerc | its not as easy, but it can be done | 04:07 |
| ricardokirkner | can you give me some pointers for that? | 04:07 |
| chandlerc | just a sec, lemme look through the docs again and refresh myself | 04:07 |
| chandlerc | ricardokirkner: https://planning.acm.org/hq/documentation/version-control/installing-bzr-svn does this not work for you? | 04:09 |
| chandlerc | eh, reading that, those instructions look moderately suspect | 04:10 |
| ricardokirkner | chandlerc, no, I tried that, but it more-or-less breaks the whole distro :-p | 04:12 |
| ricardokirkner | I think it is a bit outdated | 04:12 |
| chandlerc | k | 04:13 |
| chandlerc | can you install things on the system itself, or do you need it installed in the home dir? | 04:13 |
| mlh | ricardokirkner: don't know offhand, sorry. I was thinking of launchpad, but you're probably looking for something to host yourself/internally. | 04:13 |
| ricardokirkner | I can, but it is actually a nuisance, since I would have to do that on every developers computer | 04:13 |
| ricardokirkner | mlh, exactly, thanks anyway | 04:14 |
| mlh | rumours are that canonical will open up launchpad code sometime | 04:14 |
| mlh | what features of trac do you particularly want? | 04:16 |
| chandlerc | ricardokirkner: would home dir help you with that? | 04:16 |
| mlh | issue -> code linking? code browsing? | 04:16 |
| ricardokirkner | the thing is we are already using trac internally for all projects, and since I am trying to convince them to move from svn to bzr, I need to disrupt as little as possible | 04:16 |
| chandlerc | yea | 04:16 |
| ricardokirkner | oth, trac works well enough: code browsing, diff, wiki, issues | 04:17 |
| chandlerc | my recommendation would be to keep trac, and find a way to support bzr-svn... i looked at a lot of alternatives, and it seems the lowest effort way to introduce bzr | 04:17 |
| ricardokirkner | chandlerc, maybe, if it could be done in a zc.buildout-like manner, i think it would be quite painless | 04:17 |
| chandlerc | ricardokirkner: ok, lets go through this then, but i warn you that i haven't done these exact steps myself, so ymmv | 04:18 |
| chandlerc | http://bazaar-vcs.org/BzrForeignBranches/Subversion#id35 | 04:18 |
| chandlerc | ^^ that is basically what you want to do | 04:18 |
| chandlerc | but instead of "./configure" you want to "./configure --prefix=/home/username" | 04:19 |
| ricardokirkner | chandlerc, you mean installing subversion 1.5 in the home dirs, and then somehow telling bzr to use that subversion installation? | 04:20 |
| chandlerc | yep | 04:20 |
| chandlerc | you can do one step less invasive though | 04:20 |
| ricardokirkner | is it possible to only install the bindings, without having to install the svn client? | 04:20 |
| mlh | or install to /opt if you want others to see it | 04:20 |
| chandlerc | i think (but am not 100% certain) if you can match up subversion source code version to the one installed on the system | 04:20 |
| chandlerc | you can "make install-swig-py" only | 04:20 |
| chandlerc | and then just manipulate the Python environment variables to include the correct /home/username/lib/python... path | 04:21 |
| chandlerc | i'm not a python guru, so that part I can't help as much with | 04:21 |
| chandlerc | mlh: i think he wants to do something like re-tarball it all up post-installation so that each user can do a one-time untar and magically have it sitting in their home directory | 04:22 |
| ricardokirkner | mhhh... I can try that... so if I could manage to install the python bindings locally (say to the home folder), I might even write a zc.buildout recipe that installs bzr (and all its dependencies including bzr-svn) to a developers sandbox | 04:22 |
| chandlerc | mlh: /opt would require sudo or su access or the equivalent | 04:22 |
| mlh | oh yeah | 04:22 |
| chandlerc | ricardokirkner: i dunno anything about zc.buildout | 04:22 |
| ricardokirkner | permissions are not an issue | 04:22 |
| chandlerc | if permissions aren't an issue, then yea, use --prefix=/opt | 04:23 |
| mlh | then /opt/subversion-v.x.z si a better option then | 04:23 |
| chandlerc | and hell, you can roll out a full subversion-1.5.x install, and have people just use that version of subversion | 04:23 |
| ricardokirkner | and how do I tell bzr to use the /opt subversion? | 04:23 |
| mlh | I do that for solaris, and make a symlink /opt/subversion to the current version | 04:23 |
| chandlerc | same way for local | 04:23 |
| chandlerc | you just have to manipulate the Python search paths to find python libraries within the install tree | 04:24 |
| chandlerc | whatever that install tree is | 04:24 |
| ricardokirkner | supposing I dont want to modify the default subversion version | 04:24 |
| chandlerc | then find the sources for that exact version (including patches if possible) and just build install-swig-py | 04:24 |
| chandlerc | er, just "make install-swig-py" | 04:24 |
| ricardokirkner | chandlerc, ok, so I just prepend the /opt/ paths before the /usr paths and that should do it, right? | 04:24 |
| chandlerc | ricardokirkner: theoretically... i'd follow mlh's suggestion and make it "/opt/subversion-1.4.?-pypatch" or something to distinguish it | 04:25 |
| chandlerc | but you can make Python look anywhere you please for its python libraries | 04:25 |
| chandlerc | and bzr-svn just uses Python to "import" stuff | 04:25 |
| ricardokirkner | chandlerc, ok, great... I will look into it then tomorow at work... | 04:26 |
| chandlerc | with the correct Python environment variables, you can have it look first in your custom rolled subversion python bindings directory | 04:26 |
| ricardokirkner | thank you both for your suggestions | 04:26 |
| chandlerc | what those might be, i can't help much with, being relatively ignorent of python | 04:26 |
| chandlerc | but that at least will be well documented | 04:26 |
| chandlerc | np, feel free to ping me if you run into issues | 04:26 |
| chandlerc | i use bzr-svn heavily for this exact purpose | 04:26 |
| chandlerc | (no offense to launchpad, but googlecode is more to my minimalist style) | 04:27 |
| ricardokirkner | chandlerc, another question. so when using bzr-svn, you have found out that there are no issues due to the interoperability of bzr and svn? (i mean, nothing breaks) | 04:27 |
| ricardokirkner | what version are you using ? (of bzr-svn) | 04:28 |
| chandlerc | latest iirc | 04:29 |
| chandlerc | i had one terrifying data-loss incident, but that was (i am mostly convinced) due to my own terrible mistakes. i was trying to do something i should not (and could not) do | 04:30 |
| chandlerc | it ended up reverting a bzr repo to revision 1 | 04:30 |
| chandlerc | that was sad | 04:30 |
| chandlerc | however, i recovered all the data by pulling back down from subversion... so no real problem with bzr-svn there | 04:30 |
| ricardokirkner | that's not good pr :-) | 04:30 |
| ricardokirkner | ah, ok | 04:31 |
| chandlerc | eh, it just a "feature" of bzr... if you only have one branch around, and do something royally dumb.... | 04:31 |
| chandlerc | my mistake was the only one branch part | 04:31 |
| ricardokirkner | so it commited everything fine, and you could grab latest version from svn | 04:31 |
| chandlerc | yep | 04:31 |
| ricardokirkner | all through bzr-svn | 04:31 |
| chandlerc | yep | 04:31 |
| ricardokirkner | that is good pr :-) | 04:31 |
| chandlerc | here, take a look at an active repo if you like: http://code.google.com/p/inc/ | 04:31 |
| pickscrape | Sorry to interject, but why was trac considered to not be a good fit for bzr? | 04:32 |
| chandlerc | nfc | 04:32 |
| pickscrape | We were hoping to use it ourselves | 04:32 |
| chandlerc | the python web app apparently meshes better with non-python vcs than with python vcs... go figure | 04:32 |
| chandlerc | i worked on trac briefly... i was not impressed by their internal design. thats where i would look first for reasons why it didn't work out | 04:33 |
| pickscrape | By that I presume you mean it also has issues with mercurial? | 04:33 |
| ricardokirkner | chandlerc, well, svn already existed long time before svn, so it actually makes sense | 04:33 |
| chandlerc | ricardokirkner: oh i know, svn support being better makes sense. git and mercurial support before bzr is a little unusual | 04:33 |
| ricardokirkner | I mean trac existed before bzr | 04:34 |
| chandlerc | true as well | 04:34 |
| bob2 | isn't trac from like late 2004 | 04:34 |
| chandlerc | they really struggled making their system interoperate with other VCSes back when i was working on the project. i dunno if they've gotten all the cruft refactored, but back then it was pretty awful | 04:34 |
| bob2 | ah, early 2004 | 04:35 |
| pickscrape | The framework is basically all plugins now from what I know. | 04:35 |
| chandlerc | i never looked back. retrospectiva is a much saner web app if that's what you need, and for project hosting i enjoy googlecode | 04:35 |
| chandlerc | i'd love to see something like retro done in python on top of turbo gears or django in order to cooperate nicely with all the python bindings for VCSes out there | 04:35 |
| ricardokirkner | yeah, might be, but trac make sense for internal application design | 04:35 |
| ricardokirkner | where you don't want to host your code outside | 04:36 |
| chandlerc | ricardokirkner: retro = trac on ruby on rails | 04:36 |
| chandlerc | ricardokirkner: its perfectly well suited to that use case, i was tasked with working on such a design at a previous company | 04:37 |
| pickscrape | In Trac 0.10, the VCS backend is entirely a plugin (AIUI), so theoretically you should be able to shove anything in there. | 04:37 |
| ricardokirkner | chandlerc, well..... looking at the tickets list, the first one is 'Multiple SCM support' , so apparently they too haven't solved it yet | 04:37 |
| chandlerc | ricardokirkner: correct, i've been using svn as a multiple SCM support layer because git, mercurial, and bzr all will speak svn | 04:38 |
| chandlerc | pickscrape: the problem is that shoving stuff into trac is notoriously challenging | 04:38 |
| chandlerc | pickscrape: but yes, you could build a plugin for trac, and it probably wouldn't be terrible to do | 04:38 |
| ricardokirkner | well, thank you guys, I'll be off now... I'll try your suggestions tomorrow | 04:39 |
| pickscrape | But the plugin already exists. | 04:39 |
| chandlerc | =] goodluck! and keep with the bzr! | 04:39 |
| chandlerc | pickscrape: it does? | 04:39 |
| * ricardokirkner waves good-night | 04:39 | |
| pickscrape | Yes, there's a trac bzr plugin | 04:39 |
| pickscrape | https://launchpad.net/trac-bzr | 04:39 |
| ricardokirkner | yes, that is what I am using | 04:39 |
| pickscrape | Last commit was March this year. | 04:41 |
| pickscrape | Anyway, I'm off to bed. :) | 04:42 |
| poolie | hello | 05:11 |
| lifeless | (v1, 'unknown verb') | 05:16 |
| * igc picking up kids - bbiab | 05:43 | |
| gnomefreak | anyone here that can give me a hand with an error when pushing a bzr branch to LP? | 05:51 |
| spiv | gnomefreak: sure, what's the error? | 05:51 |
| gnomefreak | spiv: 1 sec im getting it and i will pastebin it | 05:52 |
| * gnomefreak cant open browser | 05:54 | |
| gnomefreak | spiv: gnomefreak@Development:~/extensions_build$ bzr push bzr+ssh://gnomefreak@bazaar.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu | 05:54 |
| gnomefreak | Permission denied (publickey). | 05:54 |
| gnomefreak | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 05:54 |
| gnomefreak | sorry my browser isnt working | 05:54 |
| mwhudson | there's a clue in there | 05:54 |
| mwhudson | "Permission denied (publickey)." | 05:54 |
| gnomefreak | mwhudson: permissions | 05:54 |
| gnomefreak | yes but why | 05:54 |
| gnomefreak | my .ssh has wrong permissions? | 05:55 |
| spiv | gnomefreak: that's openssh's way of saying it can't authenticate with the server | 05:55 |
| spiv | probably because the SSH key you have on your computer doesn't match the public key(s) you have in Launchpad. | 05:55 |
| mwhudson | gnomefreak: could be that, or more likely you don't have the correct key in your key agent or something | 05:55 |
| mwhudson | gnomefreak: you could try | 05:55 |
| mwhudson | ssh -vv gnomefreak@bazaar.launchpad.net | 05:56 |
| gnomefreak | permission denied as well | 05:56 |
| mwhudson | i can connect to the server ok, so it's /probably/ not some system wide problem | 05:56 |
| mwhudson | you should have got a page or two of output first | 05:56 |
| gnomefreak | my key shouold be fine since i got it from usb stick | 05:56 |
| gnomefreak | mwhudson: i did | 05:56 |
| mwhudson | well, did it should ssh presenting the key you expected to work? | 05:57 |
| spiv | mwhudson: s/should/show/ | 05:57 |
| mwhudson | spiv: thanks | 05:57 |
| gnomefreak | mwhudson: ran out of reading it over atm | 05:57 |
| gnomefreak | s/ran/reading | 05:57 |
| gnomefreak | oh no sorry 2 posts niether complete | 05:58 |
| gnomefreak | debug1: Host 'bazaar.launchpad.net' is known and matches the RSA host key. | 05:59 |
| gnomefreak | debug1: Found key in /home/gnomefreak/.ssh/known_hosts:1 | 05:59 |
| gnomefreak | that tells me it works no? | 05:59 |
| mwhudson | no | 05:59 |
| spiv | No, that's the host key | 05:59 |
| gnomefreak | oh | 05:59 |
| spiv | That's just SSH checking that the server isn't being spoofed. | 06:00 |
| gnomefreak | thats odd shouldnt there be more than one file in ~/.ssh? | 06:00 |
| gnomefreak | only one there is known_hosts | 06:01 |
| spiv | If you have a keypair, yes, there should be. | 06:01 |
| gnomefreak | i might have forgotten to grab dir off usb stick after i reinstalle | 06:01 |
| spiv | Typically you'd also have "id_dsa" and "id_dsa.pub", if you have a DSA keypair. | 06:01 |
| gnomefreak | d | 06:01 |
| gnomefreak | i got password dialog | 06:03 |
| gnomefreak | looks like bzr crashed | 06:03 |
| gnomefreak | http://pastebin.mozilla.org/429931 is what i get when trying to push | 06:05 |
| mwhudson | now _that_ is obscure | 06:06 |
| gnomefreak | that is bzr problem not so much LP or me right? | 06:06 |
| mwhudson | well, i guess it's a bzr-svn problem | 06:07 |
| mwhudson | gnomefreak: can you try again with --no-plugins | 06:07 |
| gnomefreak | k | 06:08 |
| gnomefreak | that got rid of traceback issue | 06:09 |
| gnomefreak | that looked like it worked with --no-plugins and --use-existing-dir | 06:10 |
| spiv | gnomefreak: please file a bug on bzr-svn with that traceback, I'm fairly sure that's not meant to happen | 06:11 |
| gnomefreak | spiv: will do shortly | 06:11 |
| spiv | gnomefreak: thanks! | 06:12 |
| gnomefreak | anytime. thanks for the help :) | 06:12 |
| dhd | hi - I want to take one repository and import it into a subdirectory of another repository - how do I do this? | 06:13 |
| jamesh | dhd: you can use "bzr branch" to move each branch in the first repository to the second | 06:20 |
| bob2 | multi-pull or repo-push might help automate it | 06:21 |
| gnomefreak | spiv: mwhudson the bug is filed its bug 229819 please let me know if more info is needed, thanks again for your help | 06:22 |
| ubottu | Launchpad bug 229819 in bzr "bzr-svn gave traceback during push" [Undecided,New] https://launchpad.net/bugs/229819 | 06:22 |
| === cpro1 is now known as cprov | ||
| === abentle1 is now known as abentley | ||
| === guilhemb is now known as guilhem | ||
| === guilhem is now known as guilhembi | ||
| === guilhembi is now known as guilhembi_ | ||
| nbjayme | hello every one. i have a branch that i created under a shared repository and I don't need it anymore. Is it okay to just delete it? or is there a proper way to delete a branch under a shared repo. | 10:22 |
| nbjayme | ? | 10:22 |
| james_w | nbjayme: just deleting it is fine | 10:27 |
| nbjayme | thanks james_w. | 10:27 |
| james_w | however the space taken up by its unique revision data will not be freed. | 10:27 |
| james_w | there's currently no garbage collection command to do this, if it is going to be significant for you you can do it by hand, creating a new shared repository and branching over all the other braches. | 10:28 |
| nbjayme | okay. thanks for that helpful tips. it'll help me in informing the participants during the Bazaar workshop. :) | 10:29 |
| nbjayme | one more thing, supposing i created branchA under a shared repo than later on I renamed it as BranchB will bzr still relate the commits of BranchB to BranchA (it's previous name)? or will bzr create another repository batch different for BranchB unrelated to previous commit when it was Branch A...? | 10:33 |
| nbjayme | i assume bzr doesn't care whatever the name of the branch under the shared repo. as long as it keeps the .bzr folder files intact. am I right on this? | 10:34 |
| nbjayme | yep. it did. thanks for the info and patience. | 10:37 |
| Peng | Augh, I was just about to say that to him. | 10:38 |
| Kamping_Kaiser | what if you add something youve already added? does bzr simply ignore you? | 11:59 |
| spiv | Kamping_Kaiser: right | 12:00 |
| Kamping_Kaiser | spiv, thanks | 12:01 |
| === mwhudson__ is now known as mwhudson | ||
| gour | hi | 12:25 |
| gour | i just read http://www.infoq.com/articles/dvcs-guide and see that it says that "end of line conversions" is planned for bzr-1.6. what it is exactly and any eta for 1.6? | 12:32 |
| gour | i.e. does it refer to unix/mac/win stuff or text vs. binary? | 12:33 |
| spiv | gour: we release on a monthly schedule, more-or-less. | 12:35 |
| spiv | 1.5 is due out at the end of this week, so 1.6 should be about a month after that. | 12:36 |
| spiv | It refers to unix/mac/win stuff, if I understand your meaning correctly. | 12:36 |
| spiv | i.e. the ability to say "these files are text files, and so please do the Right Thing with their line endings depending on my platform" | 12:37 |
| spiv | There's a bunch of recent discussion on the mailing list with the details. | 12:38 |
| gour | spiv: very nice. i'm looking for (possible) alternative to darcs (for a haskell project) and see there are some gui tools available for bzr for win32 users ;) | 12:38 |
| spiv | Yeah, that's an area of active development. | 12:38 |
| * gour is looking at ml | 12:38 | |
| gour | git is way too complicated to push to my dev-friends | 12:39 |
| * spiv nods | 12:39 | |
| spiv | We try to make bzr a pleasure to use. It's not perfect, but we're working on that :) | 12:40 |
| gour | i was looking at hg as well when wanting to move from darcs, but stayed with darcs; darcs-2 is nice but no gui tool for windoze and future is also not certain | 12:41 |
| gour | i anticipate that decentralized workflow with human gatekeeper would be our choice | 12:42 |
| gour | rcs should be a tool to help and not spending weeks to master it. one reason i like darcs | 12:42 |
| spiv | Exactly. | 12:43 |
| spiv | Do let us know if we're doing a good job on that front or not :) | 12:44 |
| spiv | Feedback from new users is always good to have. | 12:44 |
| gour | sure. will play a bit with it and try gui tools. | 12:44 |
| gour | anyone can give brief comparison with darcs? | 12:45 |
| * gour is researching how is bzr supported with emacs | 12:46 | |
| spiv | Someone probably can, but not me I'm afraid. | 12:46 |
| spiv | Some of our developers use emacs, so I assume quite well :) | 12:47 |
| gour | spiv: ok. thans | 12:47 |
| spiv | (I'm a vim user, so again, not much help for you!) | 12:47 |
| gour | *thanks | 12:47 |
| spiv | I think there's a generic "DVCS" mode or something that apparently supports bzr quite well. | 12:47 |
| * gour migrated to emacs some months go | 12:47 | |
| gour | *ago | 12:47 |
| gour | right, that's the one with bad support for darcs - http://download.gna.org/dvc/ | 12:48 |
| === mrevell is now known as mrevell-lunch | ||
| gour | heh, DVC uses bzr | 12:50 |
| spiv | :) | 12:51 |
| spiv | emacs itself is planning to use bzr as well, I believe. | 12:51 |
| gour | yeah, but it's not easy | 12:53 |
| gour | eol is huge topic, indeed... | 13:08 |
| * gour --> lunch. bbl | 13:08 | |
| pickscrape | Is there any way to silence the DeprecationWarning messages? | 13:47 |
| * gour just installed bzr-gtk on his archlinux machine, but it crashes | 13:55 | |
| gour | here is the trace - http://rafb.net/p/uqKwzD16.html | 13:55 |
| gour | bzr --version ==> 1.3 | 13:56 |
| === mrevell_ is now known as mrevell | ||
| jelmer | gour: that's a known issue. for now, you need to have seahors einstalled | 13:57 |
| jelmer | *seahorse | 13:57 |
| gour | ahh, i recently got rid of xfce running xmonad + xmobar only | 13:59 |
| gour | ok, will tolerate it for testing purposes - only 2 extra pkgs | 14:00 |
| gour | jelmer: thanks. now it works | 14:01 |
| gour | btw, it's nice to see bzr's initial screen with basic commands :-) | 14:02 |
| gour | although (now) git presents saner interface as well | 14:03 |
| gour | what is the use-case for for bzrtool's rspush command over builtin push? | 14:09 |
| bob2 | it was a lot faster, back in the day | 14:15 |
| gour | heh | 14:17 |
| * gour is curios whether to install bzrtools or not | 14:18 | |
| gour | mostly due to shelve command | 14:18 |
| bob2 | shelve is handy | 14:20 |
| bob2 | as is cdiff | 14:20 |
| gour | cdiff? not seeing it as part of tools | 14:21 |
| gour | by reading several posts today, i got impression that bzr is improving in speed-issues, so i wonder about the issue described here http://dave-programming.blogspot.com/2008/04/switching-to-mercurial.html ? | 14:43 |
| james_w | network perforance is known to be the biggest performance weak-spot at the moment, and it is being worked on | 14:44 |
| james_w | v3 of the smart server protocol will land soon, and that will provide a base on which to speed up a lot of operations. | 14:45 |
| james_w | I don't know all the details though, so if you want to know more about what is in v3 you will have to ask someone more knowledgeable, sorry. | 14:45 |
| james_w | in that specific case though I imagine that the server is not performing the diff, and as such all of the data for the file is being downloaded. | 14:46 |
| james_w | I might be completely wrong there, but it would probably account for the time it took. | 14:46 |
| gour | james_w: thank you for the input | 14:47 |
| awilkins | gah. Anyone know about Java streams (not entire non-bzr related) | 14:47 |
| awilkins | Dammit, where's Guillermo when you want him | 14:47 |
| james_w | awilkins: you mean the new things in 1.5/1.6, or the old InputStream etc.? | 14:48 |
| ignas | hi | 14:48 |
| awilkins | james_w: Sockets, Input/Output streams, and blocking | 14:48 |
| james_w | hi ignas | 14:48 |
| james_w | awilkins: sorry, I don't think I can help with that, it's been a while since I did any Java | 14:48 |
| ignas | I am working on migration from svn to bzr, and the most difficult part for me is trying to come up with the new workflow and explaining it to other developers on my team | 14:48 |
| menace | when a branch from one code-development line is created.. how difficult is it to synchronize it later with this code-development-line (in svn-terms "with the trunk")? | 14:49 |
| menace | which actions have to be done? | 14:49 |
| Zindar | menace: 1000 times easier then with svn :) | 14:49 |
| ignas | i have a stab at documenting it in http://ignas.pov.lt/setting_up_bzr_schooltool_sandbox.html and would be very glad if someone with some actual bzr experience could look at it | 14:49 |
| awilkins | I've got Mr A-Ms "service" plugin going as the underlying supplier for this bzr-eclipse thing ; it makes certain operations magnificently nippy | 14:49 |
| james_w | ignas: bzr is designed to be partially compatible with svn in command line syntax, so checkout, status, diff, commit, update should get you quite some way | 14:49 |
| Zindar | menance: you simply merge in "trunk" to the development branch | 14:50 |
| menace | Zindar: i believe this, but i want to know the difference. i'm comparing several SCMS right now | 14:50 |
| Zindar | check that it looks ok | 14:50 |
| Zindar | and commit | 14:50 |
| Zindar | that's it | 14:50 |
| ignas | james_w: yeah, but management of backports of features and bugfixes from trunk to release | 14:50 |
| gour | any (ex)darcs user here? | 14:50 |
| ignas | james_w: is done quite differently | 14:50 |
| === mw|out is now known as mw | ||
| james_w | ignas: ah, in that case you want feature branches I expect | 14:50 |
| Zindar | gour: used it for tests a few years ago | 14:50 |
| awilkins | menace: For comparison with SVN ; I've been doing multi-branch merging in bzr as a project requirement for some months now and it kicks the crap out of SVN. | 14:51 |
| menace | ok, only to make sure, that i got it: i have the "main line" 1 and a a line 2 was created from 1. i edited a few things in 2 and then i merge the line 1 into line 2? | 14:51 |
| james_w | menace: "bzr merge" should be all it takes in that situation. | 14:51 |
| menace | is my suggestions of the workflow right here? :) | 14:52 |
| menace | ok | 14:52 |
| gour | james_w: anything like darcs-send & darcs-apply here? | 14:52 |
| james_w | menace: that will get all of trunk's changes since you branched in to your branch, if you want to get the changes back in to trunk that's one or two more steps. | 14:52 |
| awilkins | gour: bzr send and bzr merge | 14:52 |
| ignas | james_w: i want them, but as I can't expect everyone on the team to go read bzr documentation and learn the best practices, i have to document at least the simple use scenario for someone who wants to work on new features and deploy them without commiting to trunk | 14:52 |
| james_w | gour: take a look at "bzr send", it's not the same as "darcs send", but it's what we came up with to do a similar thing. | 14:52 |
| james_w | ignas: sure, I'll take a look at your document in a minute. | 14:53 |
| ignas | james_w: thanks | 14:53 |
| gour | thank you guys...let me read some docs... | 14:54 |
| james_w | gour: "bzr send" was written partly because of someone else saying how much better darcs was than bzr at this, so if there is anything else you miss from the send command let us know, as it might be worthwhile addition. | 14:54 |
| gour | james_w: heh, cool...i'll give you feedback... | 14:56 |
| gour | so, bundle prepared with bzr send can be merged with bzr merge? | 14:59 |
| bob2 | yes | 15:01 |
| gour | nice | 15:01 |
| * gour is reading 'plugins' page | 15:01 | |
| ricardokirkner | hi. I am trying to use bzr-svn in fedora where the subversion 1.5 python bindings haven't been backported. for that I installed subversion trunk into /opt and after that I installed bzr-svn. after pointing PYTHONPATH to /opt/subversion/lib, I get no warnings when running bzr plugins, but nevertheless I cannot correctly check out a svn branch. | 15:36 |
| ricardokirkner | when doing bzr selftest svn I get errors. | 15:36 |
| ricardokirkner | how can I make sure the /opt subversion installation is being used? | 15:36 |
| ricardokirkner | I just wiped every other subversion installation from my devel machine, so I am sure the only version I have is from svn trunk, and I am getting the following error (bzr selftest svn fails): ython: subversion/libsvn_ra/ra_loader.c:1025: svn_ra_get_log2: Assertion `*path != '/'' failed. any ideas? | 15:55 |
| asabil | ricardokirkner: not sure, but you probably also want an LD_LIBRARY_PATH | 15:57 |
| ricardokirkner | yeah... sorry, tried that too | 16:00 |
| ignas | james_w: did you find anything obvious mistakes in the document? | 16:12 |
| james_w | ignas: ah, sorry, distracted by food and secret keys, I'll look now | 16:13 |
| ignas | thanks | 16:13 |
| dato | heh, secret keys | 16:13 |
| james_w | ignas: first thing, "bzr init-repo" takes a directory argument, so you don't need two commands, though making it clear that a directory is being created might be useful. | 16:17 |
| ignas | i see | 16:19 |
| james_w | is your aim for people to just create the branches, and then you will be the gatekeeper who does the merges? | 16:19 |
| ignas | yes, as I am responsible for making releases, so I decide what goes where and when most of the time | 16:21 |
| ignas | it used to be that everything was being commited to trunk and i would have to fish out the revisions to backport myself | 16:21 |
| ignas | so it kind of transferrs that part of the job to other commiters now ;) | 16:21 |
| ignas | as this is the initial step of migration, i am trying to keep it simple, and not explaining how one would go about merging changes + backporting them to releases himself | 16:22 |
| james_w | I see you explain feature branches later, cool. | 16:22 |
| james_w | I like the title of the last section :-) | 16:22 |
| james_w | it looks pretty good though, I can't see any obvious errors, and you've covered the big things. | 16:23 |
| ricardokirkner | when using bzr to handle svn branches, is merging done by bzr or by svn? | 16:23 |
| ignas | james_w: well - it is a major increase in complexity compared to "we use svn and commit everything to trunk" workflow ... | 16:24 |
| james_w | ricardokirkner: bzr | 16:24 |
| gour | if i want to provide public mirror of my local repo via bzr push, there is no need for bzr on the server? | 16:24 |
| james_w | ignas: yep, but you don't need to convince me of the benefits :-) | 16:25 |
| ignas | :) | 16:25 |
| james_w | gour: no, but you get increased performance if there is. | 16:25 |
| james_w | gour: you can just "bzr push sftp://..." and then if that location is accessible via http people can just do "bzr branch http://..." | 16:26 |
| ricardokirkner | james_w, so if I manage my branches with bzr, but have those branches stored in a centralized svn repository, I get all the benefits from bzr (decentralized, good merging, ...) but everything is stored by svn, | 16:26 |
| james_w | ricardokirkner: I think it should all work fine from bzr's view | 16:26 |
| gour | james_w: does push works over ssh as well? | 16:26 |
| ricardokirkner | I am trying to figure this out, because I am trying to push the use of bzr at my work, where everything is svn right now | 16:27 |
| james_w | ricardokirkner: however, I don't know what the svn client will think has happened. I imagine it all works fine, but it has no idea the branches have had any interaction. | 16:27 |
| ricardokirkner | and unfortunately I am struggling with bzr-svn because fedora (which is what they use here) doesn't have the 1.5 bindings backported yet | 16:27 |
| james_w | gour: sftp:// is ssh, you can use bzr+ssh:// if the server has bzr installed. | 16:27 |
| james_w | ricardokirkner: yeah, I saw that, that's a shame. | 16:28 |
| gour | james_w: but sftp requires some setup on the server, right? | 16:28 |
| ricardokirkner | james_w, I just saw in svn that they have 1.5-rc5, do you think it will be long before they release 1.5? | 16:29 |
| james_w | gour: I don't think so, I don't know if it's real sftp, or just the name we use for it. I suspect the former, but it required no setup here, and I've never seen anyone ask how to get it to work. Do you have a setup that wouldn't be expected to have this already? | 16:30 |
| james_w | ricardokirkner: I have no idea I'm afraid. | 16:30 |
| ricardokirkner | ok... thanks anyway | 16:31 |
| james_w | ricardokirkner: I know jelmer was also working on avoiding the 1.5 bindings altogether by implementing his own with pyrex, I don't know if that will happen before svn 1.5 | 16:31 |
| gour | james_w: i'll check it right now | 16:31 |
| james_w | gour: it works fine with no setup on a Debian/Ubuntu server at least. | 16:31 |
| james_w | ricardokirkner: I'm just going to look if anyone has ever requested fedora backport the bindings. | 16:32 |
| * gour is doing bzr push...let's see | 16:38 | |
| gour | kind a slow... | 16:39 |
| gour | ok, the repo is pushed, now lets pull back... | 17:01 |
| gour | it works...cool | 17:03 |
| jelmer | ricardokirkner: try bzr-svn 0.4.98 | 17:22 |
| ricardokirkner | what changed? | 17:22 |
| jelmer | regression | 17:24 |
| ricardokirkner | sorry jelmer , 0.4.98? or 0.4.9 or 0.4.8? | 17:24 |
| jelmer | 0.4.9 | 17:24 |
| ricardokirkner | ok | 17:24 |
| jelmer | svn is more picky about input parameters | 17:24 |
| ricardokirkner | jelmer, now the tests fail with No default access_method or index any more | 17:29 |
| ricardokirkner | and the checkout also fails, but with python: Objects/classobject.c:2281: instancemethod_dealloc: Assertion `g->gc.gc_refs != (-2)' failed. | 17:29 |
| jelmer | ah, yes - you'll need bzr < 1.4 for 0.4.9 to work :-( | 17:31 |
| ricardokirkner | ouch | 17:32 |
| ricardokirkner | ok, i'll try | 17:32 |
| ricardokirkner | do you know anything about the checkout error? | 17:32 |
| ricardokirkner | the same error was happening before | 17:33 |
| === kiko is now known as kiko-fud | ||
| === mw is now known as mw|food | ||
| menace | did someone already tried ACLs with bazaar? | 19:03 |
| james_w | menace: what sort of ACL? | 19:06 |
| menace | Privileges of Reading/Writing to certain parts of the sourcecode repository | 19:07 |
| ricardokirkner | ok, apparently it is working (using bzr-svn in fedora), albeit only through svn:// and not through http:// | 19:08 |
| menace | hm :/ | 19:08 |
| james_w | menace: so that would have to be implemented in bzr? | 19:08 |
| james_w | in which case I haven't heard of it being implemented. | 19:08 |
| jelmer | ricardokirkner: is subversion built against libneon? | 19:11 |
| gnomefreak | is there a way once branch is pushed to remove the source files and leave debian dir. in place? i pushed the source files by mistake | 19:12 |
| ricardokirkner | mhh.... it isn't by default, I am guessing right now :-) (i just did ./configure --prefix) | 19:12 |
| ricardokirkner | i'll fix it and let you know | 19:12 |
| james_w | gnomefreak: the debian dir, do you mean that, or the .bzr dir? | 19:17 |
| gnomefreak | james_w: debian | 19:18 |
| gnomefreak | the branch should only be the debian dir and .bzr afaik the source files shouldnt be there | 19:18 |
| gnomefreak | i have a separate source branch | 19:18 |
| james_w | so you have project/.bzr and project/debian/.bzr? | 19:19 |
| === thekorn_ is now known as thekorn | ||
| === kiko-fud is now known as kiko | ||
| james_w | and you ran "bzr push" in the "project" directory when you mean to run it in "project/debian/"? | 19:19 |
| gnomefreak | james_w: https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.ubuntu should only pull debian dir not everything | 19:19 |
| gnomefreak | bzr branch lp:~gnomefreak/firefox-extensions/firegpg.ubuntu | 19:19 |
| james_w | gnomefreak: ah, so the problem isn't specifically with push, it's that you versioned all the source with bzr when you only wanted to version "debian/"? | 19:21 |
| gnomefreak | https://code.edge.launchpad.net/~gnomefreak/firefox-extensions/firegpg.upstream << should be only branch with these sources | 19:21 |
| gnomefreak | james_w: yes | 19:21 |
| gnomefreak | but i did bzr add debian | 19:21 |
| gnomefreak | and commit than push and it pushed everything | 19:21 |
| james_w | because you started with a "bzr branch firegpg.upstream firegpg.ubuntu" presumably? | 19:23 |
| gnomefreak | yeah | 19:23 |
| james_w | then that's the expected behaviour | 19:24 |
| gnomefreak | i guess easiest would be to delete branch and repush correctly | 19:24 |
| james_w | and as I understood it, this was the plan for the extension packaging. | 19:24 |
| gnomefreak | james_w: yes i know im trying to correct it | 19:24 |
| gnomefreak | james_w: there should be an .upstrewam and a .ubuntu ubuntu == debian dir upstream == upstream source fiels | 19:25 |
| gnomefreak | files | 19:25 |
| james_w | I realise that's not what's done with the firefox packages themselves currently, but I would recommend it for the extensions. | 19:25 |
| gnomefreak | upstream and ubuntu together? | 19:25 |
| james_w | yep | 19:25 |
| gnomefreak | when upstream changes we would rather not start with old upstream sources | 19:26 |
| james_w | if you like we can move this to mozillateam, as I think they would be more interested in this discussion than #bzr | 19:26 |
| gnomefreak | james_w: ok | 19:26 |
| james_w | cool | 19:26 |
| ricardokirkner | james_w, I think it is compiled with neon support. nevertheless if it works through svn it is enough for me. I can have all my branches be branches of the main branch which lies in svn (in order to have good trac support), and work with bzr on the child branches | 19:29 |
| jelmer | ricardokirkner: if libneon-dev isn't installed it will build without http support | 19:32 |
| ricardokirkner | jelmer, no, I have libneon-dev installed | 19:32 |
| jelmer | ricardokirkner: and you're using svn+http:// when specifying the URL? | 19:32 |
| ricardokirkner | no, just http (i have svn webdav installed in the web server) | 19:33 |
| jelmer | you may need to specify svn+http:// when specifying URLs to bzr because of a bazaar bug | 19:34 |
| ricardokirkner | no, something isn't working, when trying http:// or svn+http://, I get python: Objects/classobject.c:2281: instancemethod_dealloc: Assertion `g->gc.gc_refs != (-2)' failed. | 19:36 |
| jelmer | hmm, that looks like a python-subversion bug | 19:37 |
| gour | i'm inspecting emacs' DVC repo..bzr tags gives: Tags not supported by BzrBranch5. anyone can explain? | 19:54 |
| fullermd | Well, pretty much what it says :) | 20:06 |
| fullermd | The Branch5 branch format doesn't support tags. You need Branch6 for that, and apparently the branch in question isn't. | 20:07 |
| gour | i mean, how 'new' is that feature? | 20:09 |
| fullermd | That came in with 0.15 (April 1 2007). So not particularly new. | 20:10 |
| gour | ohh, it means the repos is quite old | 20:11 |
| fullermd | Well, the format still works with newer versions, so it could be being intentionally kept back for known older clients. | 20:12 |
| * gour just finished looking at ian's (igc) slides: getting started with bazaar | 20:12 | |
| gour | nice stuff | 20:13 |
| CroX | I have FTP access to a box, but not root. Could I use that for centralized development with Bazaar? | 20:53 |
| CroX | Eg, does Bazaar require any "listening software" to handle requests or can it just read the .bzr catalog and use that? | 20:53 |
| radix | hmph. | 20:54 |
| radix | CroX: You definitely don't need to run any software as root. | 20:54 |
| CroX | radix: Yeah, but do I need to run any software at all for the centralized part? I have a web hotel which I want to use to commit to. We all got dynamic IP's, so commiting and merging from eachother doesn't work too well. | 20:56 |
| radix | CroX: If all you have is an FTP account, though, you would need to share the account details with everyone who is able to commit | 20:56 |
| CroX | That would be a problem. Alright, so reading the folder with the .bzr subfolder is all that's needed. Awesome! | 20:56 |
| CroX | *wouldn't | 20:56 |
| radix | :) | 20:57 |
| === mw|food is now known as mw | ||
| === mwhudson_ is now known as mwhudson | ||
| schmichael | how bad of an idea is it to use bzr on large binary files? | 22:42 |
| schmichael | i'd like to keep all my documents including music and photos synced between computers | 22:42 |
| beuno | schmichael, probably pretty bad | 22:43 |
| pygi | ++ on that | 22:43 |
| beuno | I'd go with rsync for something like that | 22:43 |
| beuno | I've tried, it aint pretty | 22:43 |
| schmichael | beuno: ha, thanks! thats kind of what i expected, but i thought i'd check | 22:43 |
| beuno | you'll get conflicts, enourmos repos, out of memory errors... | 22:43 |
| pickscrape | Can/will that be improved as development continues, or is that likely to always be the case? | 22:44 |
| mwhudson | you can end up needing to have about three times the ram of the largest file you're versioning, or something | 22:44 |
| pickscrape | I don't particularly need to do that right now, but it's always nice to know about such things. :) | 22:44 |
| mwhudson | pickscrape: yeah, this will probably get better over time | 22:44 |
| pickscrape | Sweet. | 22:45 |
| mwhudson | i wouldn't have thought photos or music would be too terribly bad | 22:45 |
| mwhudson | isos, on the other hand :) | 22:45 |
| * pickscrape is currently writing a presentation to demo/sell bzr to his colleagues | 22:45 | |
| beuno | pickscrape, I do, on the other hand, use bzr to version large-ish binary files (50-300mb) | 22:46 |
| beuno | we do web development, and everything has to be versioned, so gfx people have their videos que large images in a repo | 22:46 |
| beuno | RAM is an issue sometimes, but bzr is getting better pretty fast | 22:47 |
| beuno | and, I bought a bigger HD :) | 22:47 |
| pickscrape | Can anyone suggest bullet points for why bzr and not hg/git? | 22:48 |
| beuno | pickscrape, igc setup a page of comparisons | 22:48 |
| beuno | but I think the failsafe answer is that bzr is mucho more user friendly in general | 22:49 |
| nDuff | pickscrape, see the web page. ease-of-use, though, is a massive one -- particular re git | 22:49 |
| nDuff | pickscrape, http://bazaar-vcs.org/BzrVsGit, http://bazaar-vcs.org/BzrVsHg | 22:50 |
| pickscrape | The annoying thing is I started out looking at git, then hg and finally bzr, but by the time I'd decided that I preferred git I couldn't exactly remember the reasons :) | 22:53 |
| pickscrape | Sorry, preferred bzr | 22:53 |
| pickscrape | Yeah, the user friendly argument works very well against git, but less so against hg. | 22:53 |
| beuno | pickscrape, if it's for an open source project | 22:55 |
| beuno | LP is a good argument too | 22:55 |
| beuno | super-cool free hosting | 22:55 |
| pickscrape | It's not, unfortunately. | 22:55 |
| mlh | not super-cool or not free ? :-) | 22:56 |
| pickscrape | :) | 22:56 |
| pickscrape | Not open-source | 22:56 |
| mlh | ah | 22:56 |
| pickscrape | Those two pages are an excellent reference, thanks! | 22:58 |
| demod | schmichael: on your question about syncing large files: have a look at "unison", it's easier to sync both ways with it than with rsync, imho | 23:02 |
| demod | beuno: is LP really such a good argument? i mean there is github (free for small projects iirc), freehg.org, etc. | 23:05 |
| beuno | demod, AFAIK, none of those have a pseudo-unlimited size, code view, revision navigation, rights managment, bugs, etc etc etc | 23:07 |
| schmichael | demod: i've looked at unison but was scared off because it sounded like its no longer maintained | 23:07 |
| demod | beuno: ok, you are probably right ,) | 23:07 |
| beuno | I don't think there's anything out there that provides something even close | 23:07 |
| pygi | beuno, gitorious will have soon | 23:08 |
| pygi | but anyway, no fights :) | 23:08 |
| beuno | demod, and, of course, you can use bzr without LP perfectly. I was just throwing ideas at him :) | 23:08 |
| beuno | pygi, well, we'll see what LP has soon :p | 23:08 |
| pygi | beuno, true :) | 23:09 |
| demod | schmichael: i believe i installed a new version a week or two ago, but can't really spot any release dates on the unison homepage atm... hm | 23:09 |
| demod | beuno: kk ,) | 23:09 |
| demod | pickscrape: btw. you really got to read the response from the mercurial team on the BzrVsHg entry imho | 23:10 |
| mlh | schmichael: I believe it's maintained; it's just very stable. | 23:11 |
| * demod should idle less | 23:11 | |
| mlh | not that I ever used it much | 23:11 |
| schmichael | demod, mlh: thanks, i'll try it out | 23:11 |
| beuno | any idea on how to get "the revision previous to X"? | 23:11 |
| beuno | by using revid | 23:12 |
| mwhudson | beuno: with the api? | 23:12 |
| mwhudson | repository.get_revision(revid).parent_ids | 23:13 |
| beuno | mwhudson, good old command line :) | 23:13 |
| beuno | maybe I could use --limit and ..revid:X | 23:13 |
| mwhudson | bzr revision-info -r $(($(bzr revno -r revid:...) - 1)) ? :) | 23:14 |
| beuno | but that gives me the revidX | 23:14 |
| beuno | mwhudson, almost! that gives me the next one (ie. X == revno 3, it gives me back revno 4) | 23:15 |
| jam | mwhudson: what is wrong with before: ? | 23:16 |
| mwhudson | jam: i didn't know about it :) | 23:16 |
| jam | beuno: bzr -r before:revid:XXXX | 23:16 |
| mwhudson | beuno: listen to jam :) | 23:16 |
| beuno | jam, that's it, thanks :) | 23:17 |
| beuno | mwhudson, ditto :) | 23:18 |
| lifeless | moin | 23:19 |
| beuno | mornin' lifeless | 23:19 |
| mwhudson | hi lifeless | 23:20 |
| beuno | yay! works! | 23:30 |
| * beuno starts preparing to release the php-bzr thingie | 23:30 | |
| mwhudson | sweet | 23:31 |
| beuno | merges are a pain in the *rs if you have to keep bzr's history in sync with a DB | 23:32 |
| beuno | vila, ^^^ | 23:34 |
| jam | beuno: merges are a pain in the stars? or did you mean *rse? | 23:44 |
| jam | What do you mean about bzr history versus DB? | 23:44 |
| jam | out of curiosity | 23:44 |
| beuno | jam, arse :) | 23:44 |
| beuno | jam, well, I have bzr's history in a DB | 23:45 |
| beuno | and, when merges happen all around | 23:45 |
| beuno | revno 177 suddenly is revno 6, with a whole lot of subrevnos | 23:45 |
| jam | beuno: well, you wouldn't have to cache the revnos :) | 23:46 |
| jam | beuno: further, a specific revno should never become anything but a dotted revno | 23:46 |
| beuno | jam, I do if the interface uses mysql to show 'em | 23:46 |
| jam | if that helps | 23:46 |
| jam | 'revno' has only 1 possible value if it is a simple integer | 23:46 |
| beuno | jam, well, it becomes part of a different revno | 23:46 |
| beuno | a merge | 23:47 |
| beuno | and I wanted to represent it properly | 23:47 |
| beuno | so, what I did up to know, is detect merges | 23:47 |
| mwhudson | launchpad has separate revision and branchrevision tables | 23:47 |
| beuno | delete the history from the DB, and re-generate | 23:47 |
| jam | beuno: if it were me, I would probably use a 2 pass check | 23:47 |
| jam | if the revision is a simple decendent from the previous tip | 23:47 |
| jam | just do some quick numbering | 23:47 |
| jam | if it isn't | 23:47 |
| jam | call branch.get_revision_id_to_revno_map() and just rebuild the cache | 23:48 |
| beuno | jam, if I could do calls to bzrlib, it would be very easy | 23:48 |
| jam | you technically only have to rebuild things that are outside of the common left-hand ancestry | 23:48 |
| beuno | but I don't want to use anything besides bzr and php | 23:48 |
| beuno | so it's bzr + xmloutput, which PHP writes into the DB | 23:48 |
| jam | beuno: write a plugin :) | 23:48 |
| jam | you're already using xmloutput | 23:49 |
| jam | so you can obviously have custom functions/plugins | 23:49 |
| beuno | hmmm | 23:49 |
| jam | beuno: if you care, 'bzr revision-info' can take multiple arguments per pass | 23:49 |
| beuno | I was hoping XMl would go into the core | 23:49 |
| beuno | and eliminate the use of plugins | 23:50 |
| jam | bzr revision-info -r -1..-2..-3..-4..-5..-6 | 23:50 |
| beuno | jam, that sounds interesting... | 23:50 |
| jam | It certainly isn't something that comes up often :) | 23:51 |
| beuno | I should see if that speeds things up | 23:51 |
| jam | beuno: alternatively you don't need the -r | 23:51 |
| beuno | anyway, I wanted to have something better than drop the history and reload | 23:51 |
| jam | bzr revision-info -- -1 -2 -3 -4 -5 | 23:51 |
| jam | beuno: if you do | 23:51 |
| jam | bzr revision-history OLD | 23:51 |
| beuno | so now I just start going back one revision until I get the same revid/revno in DB and in bzr | 23:51 |
| jam | bzr revision-history NEW | 23:51 |
| jam | if you can find how much of history is the same | 23:52 |
| jam | you only need to rebuild ones that are ancestors of the tips | 23:52 |
| jam | but it sounds like you might be doing that anyway | 23:52 |
| beuno | jam, yes, I should try using revision-info and/ir revision-history and see if makes it faster | 23:53 |
| beuno | but, for now, I want to finish cleaning it up and open source it | 23:53 |
| beuno | then, start making it better | 23:53 |
| beuno | but that definitely sounds faster than using log -r | 23:53 |
| beuno | it got tricky when we had to re-generate 1000k revision repos into XML 30 times a day :) | 23:54 |
| jam | 1M revision repos sounds pretty big | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!