| poolie | jam, hi | 00:01 |
|---|---|---|
| poolie | and lifeless | 00:02 |
| poolie | jam, want to talk? | 00:03 |
| jam | isn't it standup time? | 00:04 |
| === Verterok|out is now known as Verterok | ||
| spiv | https://bugs.edge.launchpad.net/bzr/+bug/230902 | 00:16 |
| ubottu | Launchpad bug 230902 in bzr "BzrError: Must end write group before releasing write lock on KnitPackRepository" [High,Confirmed] | 00:16 |
| lifeless | spiv: un | 00:26 |
| lifeless | spiv: fun | 00:27 |
| poolie | jam, nicely done with setup.py, but it should be in news too | 00:27 |
| spiv | jam: I just realised there's a problem with my batching patch; mail sent. | 00:33 |
| lifeless | spiv: btw I think your batching should apply to all repos | 00:47 |
| lifeless | spiv: there is no reason to special case it for remote | 00:47 |
| lifeless | IMNSHO | 00:47 |
| spiv | lifeless: Hmm. | 00:53 |
| spiv | lifeless: I think it would penalise plain pack repos. | 00:53 |
| lifeless | spiv: index lookups for 5 keys are more efficient than 5 lookups for 1 key | 00:54 |
| lifeless | spiv: with both GI and BTGI | 00:54 |
| spiv | lifeless: e.g. if there's only one new revision, then asking about 50 revisions will cause extra work for no benefit. And doing it one-by-one with plain packs isn't so bad because it's filling the caches of the indexes AIUI. | 00:54 |
| spiv | What's GI/BTGI? | 00:55 |
| lifeless | spiv: tell you what; test it :) | 00:55 |
| lifeless | graphindex btreegraphindex | 00:55 |
| spiv | Ah ok. | 00:55 |
| lifeless | kiko: why have you moved the download instructions lower on the front page? | 01:00 |
| lifeless | kiko: they used to be lower and we moved them to the top based on feedback from users of the web site | 01:00 |
| kiko | lifeless, because I had to scroll to read what it was. | 01:01 |
| lifeless | kiko: yes, thats the tradeoff we made | 01:02 |
| kiko | a bad one. but it's fixed now. | 01:03 |
| lifeless | kiko: another one, and this one matters more, is why you've just moved the toc to the bottom of the workflows page | 01:03 |
| === kiko is now known as kiko-zzz | ||
| lifeless | its entirely useless there | 01:03 |
| kiko-zzz | lifeless, yeah, maybe we should just remove that ToC entirely, I'm not sure | 01:03 |
| lifeless | kiko-zzz: its a long page, I think it needs a toc | 01:03 |
| kiko-zzz | yeah.. ok | 01:03 |
| kiko-zzz | I wish we could at least float the damn toc or something | 01:04 |
| kiko-zzz | but it would fight with the sidebar | 01:04 |
| lifeless | just put it under the intro | 01:04 |
| lifeless | right before solo | 01:04 |
| kiko-zzz | that page is a bit of a mess | 01:06 |
| lifeless | thanks for putting the toc back | 01:12 |
| kiko-zzz | the images should be like 1/3rd of the size | 01:12 |
| kiko-zzz | maybe tomorrow | 01:12 |
| lifeless | I'm not sure the welcome page is better; but I let others worry about that | 01:12 |
| kiko-zzz | I'm absolutely sure it's better, luckily | 01:12 |
| kiko-zzz | man who do I have to kill to get some food in this office | 01:12 |
| lifeless | kiko-zzz: you just reminded very strongly of linus | 01:13 |
| lifeless | absolute confidence, and yet, still wrong | 01:14 |
| kiko-zzz | at least I get it done | 01:14 |
| kiko-zzz | now get out of my way :) | 01:14 |
| jml | lifeless: for a minute there I was thinking you meant the Peanuts character. | 01:16 |
| lifeless | jml: perhaps I was | 01:16 |
| jml | lifeless: it doesn't gel. | 01:17 |
| lifeless | jml: ah, then perhaps I wasn't | 01:17 |
| poolie | kiko-zzz, maybe we should really split the wiki from the web site | 01:20 |
| poolie | it's hard to make it look slick in moin | 01:20 |
| kiko-zzz | yeah, it's an idea. for now I think it's okay but it needs a facelift for december | 01:21 |
| kiko-zzz | maybe just a moin facelift, but maybe something more nicer | 01:21 |
| lifeless | what happens in december? | 01:21 |
| poolie | the end of the year :) | 01:22 |
| kiko-zzz | xmas | 01:22 |
| kiko-zzz | gifts | 01:22 |
| kiko-zzz | vacations | 01:22 |
| kiko-zzz | god's last 3 gifts to mankind | 01:22 |
| poolie | 'myrrh... how nice!' | 01:22 |
| poolie | makes a change from socks | 01:23 |
| poolie | lifeless, more seriously i think kiko was wanting us to have something exciting and public happen before then | 01:24 |
| poolie | repostiory stuff will be exciting, but maybe not ready for wide use | 01:24 |
| markh | "tests suite passes on all major platforms" would possibly qualify as exciting and public :) | 01:25 |
| poolie | that is pretty exciting | 01:27 |
| poolie | is that true on windows at the moment, or not quite? | 01:27 |
| markh | will be exciting :) No movement on the LockContentionErrors AFAIK | 01:27 |
| markh | I need guidance on how to handle them before I can progress on it | 01:28 |
| markh | s/handle/silence/whatever/ | 01:28 |
| lifeless | implement dirstatev2, new tree format, then silence the existing one | 01:29 |
| lifeless | or v4 or whatever the signature would reach | 01:30 |
| poolie | someone else had a problem with file locking on a mac the other day | 01:30 |
| markh | oh, I didn't think it was *that* easy! ;) | 01:30 |
| poolie | eventually we need to get away from that | 01:30 |
| lifeless | well I mailed the list with a proposal | 01:30 |
| poolie | not to say we can't take a smaller step first | 01:30 |
| lifeless | the responses seemed to vary | 01:30 |
| markh | tests are too noisy on windows so regressions will not be noticed. Silencing the test noise is IMO more important than fixing the implementation | 01:30 |
| markh | and presumably easier | 01:31 |
| === mw is now known as mw|out | ||
| poolie | markh, did you get my pm? | 01:32 |
| lifeless | markh: given that tests fail because of the implementation, I really can't agree | 01:32 |
| markh | lifeless: my concern is that regressions completely unrelated to the *known* problem of locks will be hit | 01:33 |
| markh | and experience shows that *has* happened in the past - regression have been introduced that the tests *did* see, but got lost in the noise | 01:34 |
| markh | that IMO is worse than what we already know is bad about locks on windows | 01:34 |
| lifeless | markh: selftest -v | grep 'FAILURE|ERROR' | 01:34 |
| lifeless | markh: then do that and diff, if there are + lines, its new failures | 01:35 |
| markh | lifeless: who are you saying should do that regularly? | 01:35 |
| markh | it wasn't me that introduced the regressions I'm talking about | 01:35 |
| lifeless | whoever is doing release related stuff on windows; before the release | 01:35 |
| markh | well - the end result is we end up in a catch 22 - wont fix tests until we fix the impl, impl is very hard to fix, especially on windows, as tests are too noisy to see what regressions you introduced :) | 01:36 |
| markh | but - I'm not interested in arguing this | 01:36 |
| markh | I just suggested it might be good public info to work towards and announce | 01:36 |
| markh | take it or leave it :) | 01:36 |
| markh | I'm interested in helping fix tests - but have no time to help with a dirstate impl | 01:37 |
| lifeless | markh: I don't get the catch-22, but perhaps I just have a different understanding on how the tests fit together | 01:41 |
| markh | lifeless: i think if the situation was reversed, and we had massive linux test failures due to an implementation problem, I doubt your solutions would fly - either the "live with it or provide a new impl" position or the "live with it and use grep to detect regressions" position. | 01:43 |
| poolie | hm | 01:44 |
| * jml emulates looms with branches | 01:45 | |
| poolie | > Silencing the test noise is IMO more important than fixing the implementation | 01:45 |
| poolie | i mostly agree, getting to a known reliable state is a good first step | 01:45 |
| markh | We *know* all about the lock problems. We *don't* know about new regressions | 01:46 |
| poolie | right | 01:46 |
| markh | bbiab | 01:46 |
| lifeless | markh: actually, I use the diff approach when I'm dealing with horribly broken branches, which happen when I do some of the heavy lifting I do regularly | 01:47 |
| lifeless | markh: if I was a windows dev, I would be hacking on the tweaked implementation at top speed because that would permanently fix this issue | 01:47 |
| lifeless | markh: but I'm not a windows dev, so even if wrote a new impl for you (which really is quite small, ~500 lines totall diff I think) I couldn't be sure it had fixed things for windows | 01:48 |
| lifeless | markh: you seem to feel I'm not helping, so I'll drop it | 01:49 |
| lifeless | poolie: silencing the test noise doesn't get us a known reliable state | 01:49 |
| poolie | ok i'm going to look at this usertest thing with spiv | 01:52 |
| lifeless | I thought someone wrote a stats gatherer that determines by annotate the contributors to the code base | 02:06 |
| lifeless | (rather than commit cout, which is... crude) | 02:06 |
| spiv | lifeless: maybe abentley did? | 02:12 |
| jml | ooh, fancy: "You can restore the old tip by running:..." | 02:18 |
| lifeless | poolie: bzr 1.8. branch created | 03:16 |
| === abadger19991 is now known as abadger1999 | ||
| teratorn | anyone alive that knows about bzr-svn internals? got a bug that I wouldn't mind talking about: https://bugs.launchpad.net/bzr/+bug/277369 | 04:08 |
| ubottu | Launchpad bug 277369 in bzr-svn "Push to SVN: exceptions.AttributeError: children" [Undecided,Fix released] | 04:08 |
| jelmer | teratorn, Yeah, I just closed that one, it's already fixed | 04:08 |
| teratorn | jelmer: oh wow that rocks | 04:08 |
| teratorn | jelmer: in trunk? | 04:08 |
| jelmer | teratorn, Not exactly sure what version, 0.4.13 for sur ehas the fix | 04:09 |
| teratorn | oh, heh. well I just commented on the bug after having upgraded to the latest release | 04:09 |
| poolie | nicely done | 04:10 |
| teratorn | I mean, it still crashes :) | 04:10 |
| jelmer | teratorn, You'll probably have to repush the other revisions as well | 04:12 |
| jelmer | teratorn, since the error would actually be in there | 04:12 |
| teratorn | jelmer: hmm, how would I do that? | 04:13 |
| jelmer | teratorn, the easiest way is to remove the revisions manually from svn | 04:15 |
| jelmer | teratorn, that requires administration access to it though | 04:16 |
| * jelmer gets some sleep | 04:16 | |
| teratorn | I didn't even know that was possible, with SVN | 04:16 |
| abentley | spiv: wisnae me. | 05:15 |
| gimmal | hey folks. having trouble installing bzr-xmloutput plugin. 'bzr plugins' gives me this: Unable to load plugin 'xmloutput' from '/usr/lib/python2.4/site-packages/bzrlib/plugins' # so how do I find out why it can't load the thing? | 06:30 |
| gimmal | fwiw, it's being installed for sake of bzr + eclipse eclipse plugin | 06:31 |
| markh | gimmal: check out .bzr.log - executing 'bzr version' will tell you where it is | 06:31 |
| gimmal | ok. thank you | 06:32 |
| markh | probably in ~ | 06:32 |
| gimmal | yeah | 06:32 |
| gimmal | hey do y'all have a minute to look at a paste? I'm no python student as of yet ... heh | 06:33 |
| gimmal | it boils down to this in the traceback: TypeError: __init__() got an unexpected keyword argument 'short_name' | 06:33 |
| gimmal | which is in the traceback, listed after this: File "/usr/lib/python2.4/site-packages/bzrlib/plugins/xmloutput/__init__.py", line 108, in cmd_xmlstatus | 06:34 |
| gimmal | short_name='V'), # any ideas? | 06:34 |
| gimmal | bzr version mismatch? | 06:34 |
| markh | that would be my guess | 06:35 |
| gimmal | ok; could be simple to fix, thanks | 06:35 |
| gimmal | simple, muahahah ... so i just start virtualbox, copy my /etc/apt/soruces.list to a vfat partition, move my hdd to the gateway laptop (where bzr is, and where eclipse is installed), then use gnome-terminal via an xming (xserver for vista) session ... update the apt repo on that comp, install the bzr deb from backports.org, then start eclipse (via gnome-terminal via xming) again ... pretty simple, yeah, just involving a lot of steps... | 06:38 |
| gimmal | the hdd is a portable, duhuhuhehe | 06:38 |
| gimmal | if only virtualbox was booting the virtual deb image ... it's some kind of ext2 fs support in the windows env... | 06:40 |
| gimmal | woo success ... weird wait preiod after plugging in the hdd | 06:41 |
| vila | hi all | 06:59 |
| gimmal | well thanks for the help | 07:24 |
| loswillios | hey | 07:41 |
| loswillios | I have a little problem here, bzr pull tells me to do 'bzr upgrade' to get better performance but 'bzr upgrade' says format 1 is already at the most recent format. | 07:42 |
| loswillios | anyway to solve that, or workaround the message? | 07:42 |
| jml | loswillios: perhaps it's the remote branch that needs to be upgraded? | 08:01 |
| bob2 | it may say that if it is an old rich-root format | 08:03 |
| loswillios | hm.. I guess I should do a clean check out | 08:11 |
| loswillios | jml: seems like it: even 'bzr get http://bazaar.launchpad.net/~team-mms/mms/1.1.0 mms-1.1.0' says "Format <RepositoryFormatKnit1> for http://bazaar.launchpad.net/%7Eteam-mms/mms/1.1.0/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance" | 08:15 |
| jml | loswillios: so, if you want to work around it, you need to upgrade that branch. | 08:16 |
| jml | loswillios: which is only something you can do if you are a member of ~team-mms | 08:16 |
| loswillios | I'll poke the author, thanks | 08:17 |
| === jamesh_ is now known as jamesh | ||
| _raz_ | Does someone know a solution for the push/branch issue for ftp in version 1.7 (https://bugs.launchpad.net/bzr/+bug/259855)? | 10:04 |
| ubottu | Launchpad bug 259855 in bzr "Wrong mode of .bzr files when pushed via FTP" [Medium,Fix committed] | 10:04 |
| _raz_ | looking at the 1.7 bzrdir code, the patch for it is already in, but does not resolve that issue - at least not for me | 10:05 |
| _raz_ | looking at the push result on the server, the .bzr directory and all subdirectories miss a g+x in contrast to the old behaviour | 10:08 |
| _raz_ | files accordingly lack g+r and so on | 10:10 |
| _raz_ | though this only seems to affect anything directly under .bzr, not under the directories within it | 10:12 |
| kiorky | Uhm is that normal ,that with pyrex, i can not run 'easy_install bzr' (i go into sandbox violation) | 10:26 |
| lifeless | kiorky: no idea, we generally recommend people use packages | 10:52 |
| lifeless | kiorky: we have binaries for windows, macos X and most linux distros have current packages | 10:52 |
| poolie | night all | 11:02 |
| rocky | does bzr 1.7 run on py2.6 ? | 13:09 |
| fullermd | I don't think so. | 13:09 |
| fullermd | vila is doing some work on that. | 13:09 |
| vila | bzr.dev should, but since 2.6final is not yet out, take it with a grain of salt... | 13:10 |
| rocky | vila: 2.6 final is out =P | 13:15 |
| rocky | jelmer: any release of bzr-svn supporting bzr 1.7 yet? or still use the 0.4 branch? | 13:15 |
| vila | oops, since when ? | 13:15 |
| jelmer | rocky, 0.4.13 | 13:16 |
| rocky | vila: lol, you must not read much python blogs ... it was released yesterday i think, i read about 50 blog posts about it ;) | 13:16 |
| rocky | jelmer: awesome, thanks | 13:16 |
| rocky | will test it out | 13:16 |
| fullermd | vila: See what you miss when you sleep? :p | 13:16 |
| vila | rocky: anyway, you're welcome to test it and report any problems, but the test suite is passing (modulo a very minor/cosmetic error) | 13:17 |
| vila | fullermd: damn, I knew it ! | 13:17 |
| vila | fullermd: I'm still wondering when *you* sleep though :) | 13:18 |
| fullermd | I'll get all the sleep I need when I'm dead ;) | 13:23 |
| jelmer | hmm, no python 2.6 in debian yet :-( | 13:24 |
| fullermd | Debian? Do they even know there's a python 2.4 yet? | 13:24 |
| rocky | lol | 13:28 |
| * rocky just finished building python2.6 on his ubuntu | 13:28 | |
| rocky | jelmer: when i "bzr co https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk ClueMapper-trunk" (you can do this too, it's an anonymous svn repo) at around rev 82 it slows down *big* time ... bzr 1.7.1 + bzr-svn 0.4.13 + svn 1.5.1 | 13:42 |
| jelmer | rocky, svn rev 82? | 13:44 |
| rocky | i guess, i'm watching the status bar | 13:44 |
| rocky | it gets to 82/156 and slows down (it's at 87 right now) | 13:44 |
| * rocky integrates cluemapper svn repo into jelmer's bzr-svn test cycles ... :) | 13:46 | |
| === thunderstruck is now known as gnomefreak | ||
| Leonidas | is it possible to manipulate a bzr branch without having a working tree? | 15:06 |
| fullermd | Depends on what manipulation you want to perform. | 15:07 |
| Odd_Bloke | Leonidas: It depends what you mean by 'manip... yeah. | 15:07 |
| Leonidas | jelmer: python 2.6 is probably not going into debian anytime soon - freeze. | 15:07 |
| Leonidas | fullermd: add files, commit stuff. | 15:07 |
| Odd_Bloke | Leonidas: It could go into experimental. | 15:08 |
| Odd_Bloke | Oh, wait, it'd be a separate package, it could go into unstable. >.< | 15:08 |
| fullermd | Well, no, since that would be manipulating a working tree. | 15:08 |
| Leonidas | Odd_Bloke: yeah, thats possible | 15:08 |
| jelmer | Leonidas, I run experimental | 15:08 |
| Leonidas | fullermd: ok, thanks. | 15:08 |
| * Leonidas runs testing and stable and backports important stuff. | 15:08 | |
| fullermd | (of course, if you dug into bzrlib, you could pretend to have a working tree in some ways, but then you sorta HAVE a WT) | 15:08 |
| Leonidas | (but as long as there are no packages, there's nothing to backport) | 15:09 |
| Leonidas | fullermd: no, thats too problematic, I'll just make me a working tree. | 15:09 |
| === kiko-zzz is now known as kiko | ||
| LarstiQ | Leonidas: those kinds of things are what a working tree is for, so no :) | 15:27 |
| LarstiQ | Leonidas: but you need not have a working tree _on disk_, you can use a memory backed tree. | 15:27 |
| === alperkanat is now known as alperkanat|away | ||
| === alperkanat|away is now known as alperkanat | ||
| === mw|out is now known as mw | ||
| === alperkanat is now known as alperkanat|away | ||
| === alperkanat|away is now known as alperkanat | ||
| abentley | Leonidas: You need a working tree to *commit*, but if you prefer, you can create a Tree and a Revision, and install those. | 16:10 |
| === kiko is now known as kiko-fud | ||
| Leonidas | Is there a low-level commit? I have a list of files which changed and want to commit them without creating files in the working tree. | 16:33 |
| Leonidas | I'm trying to understand bzrlib.commit.Commit.commit() - where does it gather the changes to the WorkingTree? | 17:03 |
| jpe | Is bzr ls --non-recursive http://url supposed to work? | 17:07 |
| === kiko-fud is now known as kiko | ||
| === mw is now known as mw|out | ||
| chadmiller | Hi all. One of my co-workers is using a SVN tree converted to BZR. In merging one tree to another, bzr complained that the files inside src/ were versioned but src itself was not. It moved src to src.moved, and added the merging files as src/... . I thought we worked around it by collating them with "find -exec mv" . Now, when he's finished merging files, "bzr commit" looks like it's removing all files. All his source files are "unknown" and "removed | 18:06 |
| chadmiller | " at the same time. What can he do? | 18:06 |
| AmanicA | Leonidas: I think its in self.builder = self.branch.get_commit_builder(self.parents, .. | 18:07 |
| Leonidas | AmanicA: yeah, I'm now currently trying to overwrite stuff in the Commit class. Fiddling with the builder was a bit too complicated. | 18:09 |
| AmanicA | yes | 18:09 |
| AmanicA | I saw its a bit complicate | 18:09 |
| AmanicA | d | 18:09 |
| LarstiQ | chadmiller: that sounds confusing | 18:10 |
| chadmiller | Well, we certainly are. | 18:11 |
| AmanicA | chadmille: it sounds like the src dir was added in 2 different branches (thus 2 different file ids) | 18:11 |
| chadmiller | -ed. not -ing. | 18:11 |
| chadmiller | AmanicA: I thought so. He insists it wasn't. The latest-common-ancestor has it, he says. | 18:11 |
| fullermd | Well, leaving aside the "how did you get src moved in the first place", if you find -exec mv'd all the files, as far as bzr is concerned they ARE removed... | 18:12 |
| chadmiller | We didn't "bzr rm" them or anything. | 18:13 |
| fullermd | But they're not where it expects them. | 18:13 |
| chadmiller | fullermd: So, it expect them in "src.moved"? | 18:14 |
| chadmiller | Which we then "bzr mv" to "src"? | 18:14 |
| fullermd | Sure. That's where it put them. I don't think your description works; the files can't be versioned while src/ is not, but if src (in the branch you merged) isn't the same as src (in your branch), you'd expect yours to end up in src.moved, and everything cascades from there. | 18:15 |
| chadmiller | Okay. I'll try that. | 18:15 |
| === sabdfl1 is now known as sabdfl | ||
| fullermd | Mass moved like that tend to lead to wackiness down the line though. I'd start with investigating why the src/'s are distinct. | 18:15 |
| chadmiller | "Conflict because src is not versioned, but has versioned children. Versioned directory." | 18:17 |
| fullermd | That sounds like src was removed on the other branch. | 18:18 |
| fullermd | If it were then re-add'd (instead of revert'd back into existence), that would explain why it's considered different. | 18:18 |
| chadmiller | fullermd: Occam's razor says it is a svn conversion bug. | 18:18 |
| fullermd | Likely. | 18:18 |
| fullermd | So, the thing to decide is, which of the src/'s is more likely to be used going forward, and which exists in other branches you may want to merge in the future, etc. | 18:19 |
| fullermd | Then you can decide which to keep. | 18:19 |
| chadmiller | "bzr: ERROR: Could not move src.moved => src: src is already versioned." | 18:19 |
| chadmiller | I'm having him "bzr mv src src.old", then "bzr mv src.moved src" | 18:21 |
| LarstiQ | that error I'd expect when he did "bzr mv src.moved src" | 18:24 |
| LarstiQ | without the .old step in between | 18:24 |
| Leonidas | AmanicA: right, bzr seems to have no memoery-API, this looks like it's goingt to be painful | 18:26 |
| LarstiQ | what? | 18:27 |
| LarstiQ | Leonidas: did you see what abentley said? And look at how bzr-svn does things? | 18:29 |
| Leonidas | LarstiQ: no, sorry - my bouncer has no backlog. | 18:29 |
| Leonidas | This is a bit of a problem, I have to reconfigure it some day. or find one which is not crappy | 18:31 |
| abentley | Leonidas: You need a working tree to *commit*, but if you prefer, you can create a Tree and a Revision, and install those using install_revision. | 18:40 |
| Leonidas | abentley: ah. This sounds easier. | 18:42 |
| Leonidas | install_revision(repository, rev, revision_tree) | 18:46 |
| Leonidas | So after I installed the revision, I have to link it to the branch. | 18:47 |
| abentley | Leonidas: Yes; Branch.set_last_revision_info | 18:48 |
| Leonidas | very nice, trying this. | 18:50 |
| chadmiller | Back next week. | 18:52 |
| fullermd | Oh, surely there aren't THAT many files to move :p | 18:52 |
| chadmiller | ideas to chad@sun.com, please. | 18:53 |
| Leonidas | I'm getting "Revision is not compatible with KnitPackRepository" when adding an empty revision (that is, it only has a revid) | 19:07 |
| === mark2 is now known as markh | ||
| === kiko is now known as kiko-phone | ||
| Arjen | How do I determine the commit in which a file was introduced? | 19:43 |
| Verterok | Arjen: bzr log -l 1 --forward <the_file> | 19:49 |
| loxs | hello, I can't find any documentation on how to setup a "smart server". could anyone help me please? | 19:54 |
| beuno | loxs, all you need is to have bzr installed on the remote server | 19:55 |
| beuno | and for clients to use bzr+ssh | 19:55 |
| loxs | you mean sftp? | 19:56 |
| beuno | no, I really mean bzr+ssh | 19:56 |
| loxs | because for this I don't need bzr installed on the remote server | 19:56 |
| beuno | right | 19:56 |
| loxs | hm, then could you please explain what do you mean by bzr+ssh | 19:56 |
| beuno | for bzr+ssh you do, because it uses the remote bzr installation to, well, be smart :) | 19:57 |
| beuno | loxs, sure | 19:57 |
| beuno | you would do: bzr branch bzr+ssh://user@host/path/to/branch | 19:57 |
| beuno | instead of: bzr branch sftp://... | 19:57 |
| loxs | ahamz... that sounds nice | 19:57 |
| loxs | and how do you manage permissions? on filesystem level? | 19:58 |
| beuno | yeap | 19:58 |
| beuno | since you're using ssh, whatever that user has read/write access to | 19:58 |
| loxs | I want to allow my developers commit to their own branches, but disallow them to commit to trunk. But for them to be able to commit to their branches, they need to have a write access to the .bzr in the main repository directory... is it safe? | 19:59 |
| beuno | loxs, they can have their own branches in their home dir | 20:00 |
| Leonidas | I need some help on this code: http://paste.pocoo.org/show/86963/ | 20:01 |
| loxs | hm, right... I can't stop thinking in svn terms... thanks for opening my eyes :) | 20:01 |
| Leonidas | I'm currently missing two things: 1) how to generate a revid 2) how to get the proper revno | 20:02 |
| beuno | loxs, :) | 20:02 |
| Verterok | Leonidas: I known nothing about commit internals, but it seems that rev_id id returned by the commit_builder | 20:10 |
| Verterok | beuno: hi | 20:12 |
| Leonidas | Verterok: yeah, me too. but CommitBuilder does not generate it, it gets it as an argument on instantiation | 20:12 |
| beuno | Verterok, ho | 20:12 |
| === kiko-phone is now known as kiko | ||
| Verterok | Leonidas: it's an argument of Commit | 20:14 |
| Verterok | Leonidas: from the docstring: " :param rev_id: If set, use this as the new revision id. | 20:14 |
| Verterok | Useful for test or import commands that need to tightly | 20:14 |
| Verterok | If null (default), a time/random revision id is generated." | 20:14 |
| Verterok | control what revisions are assigned. If you duplicate | 20:14 |
| Verterok | a revision id that exists elsewhere it is your own fault. | 20:14 |
| Verterok | apologize the big paste | 20:15 |
| Leonidas | Verterok: I know, but I don't understand where it is being generated. | 20:16 |
| Leonidas | Verterok: rev_id is None by default | 20:17 |
| Leonidas | Verterok: self.rev_id is set to None in commit() | 20:17 |
| Leonidas | but I'm missing the part where it gets generated | 20:17 |
| Verterok | Leonidas: I think this should clarify that :) "If null (default), a time/random revision id is generated." | 20:18 |
| Leonidas | the builder returns an id, so I suspect it generates it. | 20:18 |
| Leonidas | Verterok: but where is the part where it gets generated in the code? | 20:19 |
| Verterok | Leonidas: I assume in the Commit builder, beacuse if it's null, it returns a generated rev_id | 20:20 |
| Leonidas | Verterok: repository.CommitBuilder.commit() only returns the rev_id that was passed to its constructor | 20:21 |
| Verterok | mmm...maybe we are missing something :p | 20:22 |
| Leonidas | Verterok: yeah, I feel stupid/blind ;) | 20:24 |
| Verterok | Leonidas: don't feel alone :) | 20:25 |
| jam | Leonidas, Verterok: In CommitBuilder there is _generate_revision_if_needed which calls _gen_revision_id | 20:35 |
| jam | which is used if you don't supply a revision_id | 20:35 |
| jam | and _generate_if_needed is called as part of CommitBuilder.__init__ | 20:36 |
| Verterok | jam: thanks! | 20:37 |
| LaserJock | quick question, is it possible to change the committer's email address in the log? | 20:37 |
| LaserJock | would rebase do that? | 20:37 |
| beuno | LaserJock, you could do it with rebase, but it would break compatibility with anyone else who branched | 20:38 |
| Leonidas | jam: thanks, gen_revision_id was what I was looking for. | 20:38 |
| jam | LaserJock: it would be possible to do so during rebase, I don't think it specifically supportsr it | 20:38 |
| jam | beuno: that's what rebase *does* anyway :) | 20:38 |
| LaserJock | beuno: I don't care about anybody else ;-) | 20:38 |
| Leonidas | jam: can you also tell me how to get the right revno? | 20:38 |
| beuno | LaserJock, life's so much easier that way :p | 20:38 |
| jam | Leonidas: "right revno"? in what context | 20:39 |
| LaserJock | beuno: I don't do anything people care about anyway :-) | 20:39 |
| beuno | jam, you may be the right person to answer this. How can I find out what revno a revid is part of? | 20:39 |
| jam | "is part of" ? | 20:39 |
| LaserJock | ok, so related question, is it possible to have multiple email addresses in bzr? | 20:39 |
| jam | you mean when it was merged? | 20:39 |
| beuno | jam, it's merged into that revno, yes | 20:40 |
| jam | LaserJock: you can generally set a email address per branch | 20:40 |
| jam | beuno: "bzr log" ? | 20:40 |
| LaserJock | jam: ah, excellent | 20:40 |
| jam | "bzr log -r revid:XXX..-1" | 20:40 |
| beuno | jam, right. Now, let's say I need to do that through python | 20:40 |
| jam | beuno: you could use the output of 'bzrlib.tsort.merge_sort()' | 20:40 |
| jam | it is what 'bzr log file' now does | 20:40 |
| beuno | "here's a revid, give me the mainine revno it belogs to" | 20:40 |
| jam | you can see the code in log.py | 20:40 |
| * beuno looks | 20:41 | |
| jam | around line 603 | 20:42 |
| Leonidas | jam: In this context: http://paste.pocoo.org/show/86963/ | 20:42 |
| Leonidas | jam: line 1 is already replaced with something that is not static anymore | 20:42 |
| jam | Leonidas: so for the "set_last_revision_info()" call? | 20:43 |
| jam | and you aren't doing this as a commit on something else | 20:43 |
| jam | which you know the revno? | 20:43 |
| jam | I can give you a way, but some are easier/faster than others | 20:44 |
| jam | for example, if you know the revno, parent_id for the parent of this commit, then it is just revno+1 | 20:44 |
| Leonidas | jam: well, I commit this on something else. | 20:44 |
| jam | otherwise there is bzrlib.repository.get_graph().find_distance_from_null() | 20:44 |
| jam | you can look at bzrlib/graph.py find_distance_from_null | 20:45 |
| jam | to figure out what to pass it | 20:45 |
| jam | generally you'll want to give it a hint about some other revision | 20:45 |
| Leonidas | jam: actually I am now writing a converter from hg to bzr and constucting changesets. | 20:45 |
| LaserJock | hmm, I must be doing something wrong, rebase isn't working | 20:48 |
| beuno | jam, so I would sort the graph, and then iterate over it, until scheduled_nodes[-1][1] < merge_depth ? | 20:49 |
| LaserJock | there's gotta be a simple way to do this. I just want to change my email address on a branch that only has 3 revisions | 20:49 |
| Leonidas | jam: isn't revno+1 a bit too easy? The revno is this number that bzr log outputs, right? But then the revno can look something like 34.1.3 etc. | 20:50 |
| abentley | Leonidas: A commit can never produce a dotted revno, by definition. revno + 1 is exactly what commit does. | 20:54 |
| Leonidas | abentley: ok, fine. Then I can just take the last revno and add 1. | 20:56 |
| LaserJock | rebase just says there aren't any revisions to rebase :( | 20:57 |
| abentley | Leonidas: As long as the previous revision is the lefthand parent of the new revision. (Otherwise, you're not simulating commit.) | 20:57 |
| LaserJock | ok, let's try this a different way. How do I go back to a previous revision? | 21:11 |
| LaserJock | do I have to branch each revision separately? | 21:12 |
| LarstiQ | LaserJock: that depends on what you mean with "go back to" | 21:15 |
| LaserJock | ok, I just want to go through these 3 revisions and make a new branch from them | 21:15 |
| LaserJock | so I was thinking if I can get back to revision 1, then copy that over and commit, then go to revision 2, copy and commit, then same for revision 3 | 21:16 |
| LaserJock | but I don't exactly know how to go back in history | 21:18 |
| LarstiQ | LaserJock: that sounds like what rebase does, sort of | 21:22 |
| LarstiQ | LaserJock: unless you want to use those 3 actual revisions | 21:23 |
| LaserJock | well, I couldn't get rebase to work | 21:23 |
| LaserJock | it just said there was nothing to rebase | 21:23 |
| LaserJock | perhaps it's because I'm trying to rebase a whole branch | 21:33 |
| LaserJock | man, this is really frustrating | 21:33 |
| james_w | LaserJock: how are you running rebase? | 21:34 |
| LaserJock | well, I've tries several things | 21:35 |
| LaserJock | just plain bzr rebase | 21:35 |
| james_w | also, it will still leave the original email adress as author I believe | 21:35 |
| LaserJock | bah | 21:35 |
| LaserJock | I also tried --onto and -r to see what that'd do | 21:35 |
| james_w | I'd try "bzr-fast-export", edit the output, then "bzr fast-import" | 21:35 |
| LaserJock | oh, good idea | 21:35 |
| james_w | for rebase I'd guess rebase on to an empty branch would be what you want | 21:36 |
| LaserJock | I couldn't | 21:36 |
| LaserJock | it said that there was no history | 21:36 |
| james_w | ah, ok | 21:36 |
| LaserJock | I know it's not exactly bzr-specific but I can't believe how hard it is just to change the email address | 21:37 |
| james_w | well, it's designed to have immutable history | 21:38 |
| LaserJock | right, which I suppose works, except when you want to change history | 21:39 |
| LaserJock | :-) | 21:39 |
| LaserJock | james_w: well, I ended just doing bzr export into 3 directories then cp the files in an commit | 21:48 |
| Arjen | I can't get the bzr search plugin to accept multi-word multi-word strings to search for | 22:25 |
| tacone | how space efficent bzr is for binary files ? | 22:29 |
| tacone | let's say pictures (which normally doesn't get modified, just added or removed) | 22:30 |
| GPHemsley | jam: Version number for 1.7.1 still says 1.7.1-rc1 (or something else with "rc" in it; I didn't look closely) in some parts of the Mac installer/upgrader | 23:51 |
| === BasicPRO is now known as BasicHatesWin32 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!