| === mw is now known as mw|out | ||
| lifeless | abentley: pon | 00:17 |
|---|---|---|
| abentley | So I started hacking on per-file base selection yesterday, and I found a locality-of-reference problem. | 00:18 |
| lifeless | ok | 00:18 |
| abentley | The file content is stored in the versionedfile. The file type is stored in the inventory. | 00:18 |
| abentley | So to do it absolutely correctly, I'd have to retrieve all the trees for the selected revisions. | 00:19 |
| abentley | Because the selected revision may not be a file-- it may be a directory, symlink or tree reference. | 00:20 |
| lifeless | ok | 00:21 |
| lifeless | I see | 00:21 |
| lifeless | now, if the kind is the same on both tips | 00:21 |
| lifeless | does that make it easier ? | 00:21 |
| abentley | In fact, we're already assuming it's a file on both tips. Otherwise, we wouldn't need a base at all. | 00:21 |
| lifeless | so if its the same on both tips | 00:22 |
| lifeless | 3-way merge says that if the base is a different kind | 00:22 |
| lifeless | -> we'd treat is as empty of the same kind ? | 00:22 |
| abentley | Not quite. We'd still emit foo.BASE in the correct kind. But wrt the file merge, yes. | 00:23 |
| lifeless | now symlinks and dirs have an existing empty text for their revisions | 00:24 |
| abentley | AFAIK, correct. | 00:25 |
| abentley | So we can shortcut the kind check 99% of the time. | 00:25 |
| lifeless | so; and I realise this is hacky; | 00:25 |
| lifeless | if doing a 3-way custom base on two currently-file-texts, w.get_lines(custom_base) will give us [] when the kind has changed. | 00:26 |
| abentley | I hate to have it shortcutted 99% of the time, though. It makes me fear the full path won't get adequately tested. | 00:27 |
| lifeless | are you doing custom bases for symlinks and dirs too? | 00:27 |
| abentley | No. Those will get handled by the standard merger, which also handles inventory issues such as renames and executability. | 00:28 |
| abentley | I don't think those things change enough to require the same care as text files. | 00:29 |
| lifeless | so I guess I'm saying; if we're only doing custom base on (text, text) pairs; and get_lines(custom_base) will always return a suitable set of lines, ([] when the common base has a different kind), then its not a shutcut situation | 00:30 |
| abentley | By shortcut, I mean that we're avoiding retrieving the file kind from the relevant inventory. | 00:31 |
| abentley | But in the case where it's [], we will have to do so. | 00:31 |
| lifeless | I don't see that we ever need the file kind for the base if the parents are both texts; other than to write foo.BASE. | 00:32 |
| abentley | Right. But we will have to write foo.BASE. | 00:32 |
| lifeless | ok | 00:32 |
| lifeless | so lets look at that | 00:32 |
| lifeless | we write foo.BASE when we ended up doing a merge right | 00:32 |
| abentley | Right. | 00:33 |
| lifeless | now, will we avoid doing 'merges' sometimes with custom file bases ? | 00:33 |
| abentley | No, but if the BASE is not a file, we will do a two-way merge between THIS and OTHER. | 00:34 |
| lifeless | which is where [] is useful because it's just a clean degradde. | 00:34 |
| abentley | A clean what? | 00:35 |
| lifeless | degrade | 00:35 |
| lifeless | it's what 3-way degrades too | 00:35 |
| abentley | Okay. | 00:35 |
| lifeless | hmm, one sec local interrupt | 00:35 |
| lifeless | back | 00:39 |
| lifeless | wondering if we will ever get base == left or base == right with custom merge bases | 00:40 |
| lifeless | I think we can | 00:40 |
| lifeless | consider this | 00:40 |
| lifeless | at the graph level we have two lca's | 00:41 |
| lifeless | so we recurse | 00:41 |
| lifeless | its easy then for at the file level for one side to be purely an extension of the other for a single file | 00:41 |
| lifeless | so when we are considering that single file we'll not need to merge at all | 00:41 |
| lifeless | I'm going to think out lout now | 00:42 |
| lifeless | and enumerate what I think the possible cases are | 00:42 |
| lifeless | * Base is one side (common I suspect in criss-cross merges; many files won't be actually unmerges) | 00:43 |
| lifeless | * Base is the revision the graph level base had | 00:43 |
| lifeless | * Base is another inventory | 00:44 |
| lifeless | s/another inventory/from &/ | 00:44 |
| lifeless | done | 00:44 |
| lifeless | abentley: ^ | 00:54 |
| === josep17 is now known as linuxpararato | ||
| === linuxpararato is now known as josep17 | ||
| josep17 | buenas noches | 01:03 |
| josep17 | desde venezuela | 01:03 |
| abentley | lifeless: I would expect base==left or base==right to be rare. But I would imagine we can get it. I'm not sure why it matters. | 02:24 |
| abentley | We need a general solution. | 02:25 |
| abentley | Sure, I can hack up something gross to do per-file bases, but I think you ought to consider how an upcoming repo format could give us cheap access to file kind, symlink target, and maybe execute bit. | 02:27 |
| abentley | Right now, I'm re-implementing annotate merge, and it's going swimmingly. | 02:27 |
| jelmer | dato: resubmitting bzr-svn fixed it | 02:50 |
| jelmer | dato: your upload of 0.4.4-2 hadn't been processed yet, apparently | 02:50 |
| abentley | jelmer: Have you noticed that the bzr-gtk test suite is completely borked if run as part of the bazaar test suite? | 03:19 |
| lifeless | abentley: I'm pretty sure I hit it all the time. | 03:25 |
| lifeless | abentley: anyhow, our current format can give use kind/target/execute quite cheaply | 03:25 |
| lifeless | abentley: just use the same parse-a-delta-fragment logic. | 03:25 |
| abentley | Oy. Can't we do up a format where that works by design instead of being a tremendous hack? | 03:27 |
| lifeless | abentley: yes, both the ones poolie and I have been fiddling/mailing about will work by design | 03:28 |
| abentley | Awesome. | 03:29 |
| lifeless | abentley: but they largely formalise useful properties we have been able to leverage from the current format. | 03:29 |
| lifeless | abentley: I have been thinking that content object information should be pushed down to the per file graph anyhow; as metadata on the node | 03:30 |
| abentley | Well, I know the new format will do comparisons much faster, but that sounds like it would slow them down. | 03:32 |
| lifeless | abentley: I'm thinking some duplication actually | 03:42 |
| lifeless | abentley: but also there is locality of data possibilities. | 03:42 |
| lifeless | abentley: this would be a 2nd or 3rd iteration out. | 03:42 |
| lifeless | abentley: one possibility is: | 03:42 |
| abentley | Oh, by "pushing down", I thought you'd be taking it out of the inventory. | 03:42 |
| lifeless | kind + exec + content in the 'knit' | 03:43 |
| lifeless | inventory has parent + name + pointer to the knit version | 03:47 |
| lifeless | 'knit' index can pull kind + exec into it. | 03:47 |
| lifeless | abentley: the open things in my mind about whether this makes sense are what datum we actually need at the same time | 03:48 |
| abentley | For our tree-manipulation functions, we generally use inventory and file texts simultaneously. | 03:50 |
| abentley | When building a tree, to create a file, we need file_id, name, parent, kind, execute bit, and content basically simultaneously. | 03:51 |
| abentley | That's not a hard requirement. TreeTransform could work efficiently if you learned names, parents and file-ids in one pass, and everything else in a second pass. | 03:52 |
| lifeless | abentley: so its the case of status/diff when the last-mod is different and the value is the same that would be hurt | 03:58 |
| lifeless | abentley: -> how common is that | 03:58 |
| lifeless | (assuming we don't want false positives for st | 03:58 |
| lifeless | another possibility here though is to decouple the metadata graph from the content graph | 03:59 |
| abentley | This is assuming we're not diffing against a DirstateRevisionTree? | 03:59 |
| lifeless | right | 03:59 |
| abentley | So we wouldn't have the md5sum in the inventory? | 03:59 |
| lifeless | so you'd have (fileid, parentid, name, content-pointer[revid, validator]) as a graph | 04:00 |
| lifeless | and (kind, exec, content) as a graph | 04:00 |
| abentley | I'm not sure at all how common that is. Merges can produce it, though. | 04:00 |
| lifeless | you'd have a sha1, but not of the lines, of the lines & kind and exec bit | 04:00 |
| lifeless | this would for instance, allow us to start only storing one copy of 'COPYING' etc, depending on how we want to take it. | 04:01 |
| lifeless | this is all still wildly speculative | 04:01 |
| abentley | I don't think kind is a big concern. If it changes, we definitely need to get all the data. | 04:01 |
| abentley | I dunno, though. I think having all the data in the inventory might well be a win. | 04:03 |
| lifeless | I'd like to be in a position to experiment | 04:04 |
| abentley | Just because there are many operations that just want to know which files changed. | 04:04 |
| lifeless | write some arbitrary benchmarks outside bzr that simulate access patterns and the like | 04:04 |
| lifeless | maybe this is something we can reason about in march | 04:06 |
| abentley | Also, some stats on real trees might help us answer these questions about what's common better. | 04:17 |
| lifeless | abentley: indeed. So having an analyser that can report what a transformed tree would look like would be good | 04:27 |
| abentley | I'm not sure what you have in mind. The PreviewTree thing? | 04:28 |
| lifeless | nah | 04:28 |
| lifeless | just a script to take a branch | 04:28 |
| lifeless | and break it out into the things I'm talking about, without doing disk transformations, just in-memory, and report | 04:29 |
| abentley | Oh, to simulate a changed repo format? | 04:30 |
| lifeless | right | 04:30 |
| jelmer | lifeless: what breaks about it? | 04:50 |
| jelmer | s/lifeless/abentley/ | 04:50 |
| jelmer | ah, I see | 04:51 |
| lifeless | meh | 05:16 |
| lifeless | sorry about disappearing; what did I not respond to | 05:16 |
| Odd_Bloke | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 05:16 |
| Odd_Bloke | 05:03:21 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has quit [Read error: 113 (No route to host)] | 05:16 |
| Odd_Bloke | 05:15:45 -!- lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr | 05:16 |
| Odd_Bloke | Oops, got the trackbar. | 05:16 |
| Odd_Bloke | But yeah, nothing. :p | 05:17 |
| lifeless | thanks | 05:17 |
| === n2diy_ is now known as n2diy | ||
| alecwh | hello, I'm considering using bazaar for a project of mine... we're using subversion right now, because subversion is offered on Google Code, and Gna! (http://gna.org). Are there any free repository hosts that our GPL program can use (using bazaar)? | 08:07 |
| beuno | alecwh, sure, https://launchpad.net/ | 08:08 |
| beuno | it also works as a bug tracker | 08:08 |
| beuno | (and a bunch of other stuff) | 08:09 |
| alecwh | no way... it hosts a free bazaar repository? that's awesome. | 08:09 |
| alecwh | how do I set it up? | 08:10 |
| alecwh | https://code.launchpad.net/phpns/ | 08:10 |
| alecwh | This is our project | 08:10 |
| alecwh | Register branch? | 08:10 |
| beuno | alecwh, let me fetch you a how-to real quick | 08:17 |
| Peng | Hmm. I just started using LP a bit. I should look into the launchpad plugin. | 08:17 |
| beuno | alecwh, https://help.launchpad.net/FeatureHighlights/BazaarHosting might help a bit | 08:18 |
| beuno | but you basically just push to the right address with bzr | 08:19 |
| beuno | and the branch gets created | 08:19 |
| beuno | the folks at #launchpad might be able to give you more details though | 08:19 |
| beuno | it's a bit over 5am here, so I'm going to bed | 08:20 |
| beuno | good luck :D | 08:20 |
| alecwh | ok, thanks a lot bueno. ;_ | 08:21 |
| alecwh | ;) | 08:21 |
| Peng | Might be even simpler using lp: URIs. | 08:23 |
| Peng | New Pyrex release. | 09:19 |
| alecwh | How do I import a subversion repository into a bazaar repository? | 09:32 |
| Peng | alecwh: You could use bzr-svn. | 09:33 |
| alecwh | what does that do? | 09:34 |
| Peng | alecwh: bzr-svn can even allow pushing from bzr to svn. It's pretty neat. | 09:34 |
| Peng | alecwh: Well, for one thing, it imports svn repos into bzr repos. | 09:34 |
| alecwh | yeah, that's what I'm looking for. =D | 09:34 |
| alecwh | how does that look like? | 09:34 |
| alecwh | the bash command. | 09:34 |
| Peng | Not sure. | 09:35 |
| Peng | "bzr branch" might do it. | 09:35 |
| Peng | Read the docs. | 09:35 |
| alecwh | ok, thanks Peng. =) | 09:35 |
| lifeless | alecwh: www.bazaar-vcs.org/svn IIRC | 09:47 |
| alecwh | This page does not exist yet. You can create a new empty page, or use one of the page templates. | 09:47 |
| alecwh | lifeless: I got that error. | 09:47 |
| lifeless | alecwh: there is a link on it | 09:48 |
| lifeless | alecwh: to BzrSvn :) | 09:48 |
| alecwh | ok, thanks lifeless. I'll read over it. | 09:48 |
| JordanC | Hey there | 09:50 |
| JordanC | Tried to get things working with olive, but no dice/ | 09:50 |
| alecwh | hey JordanC. =D | 09:50 |
| Odd_Bloke | JordanC: Define 'no dice'. :p | 09:52 |
| alecwh | Odd_Bloke: It didn't work. | 09:53 |
| Odd_Bloke | Yeah, I got that much. :p I was hoping for something a little for specific. :D | 09:53 |
| Odd_Bloke | s/for/more/ | 09:53 |
| JordanC | I came in here a while back, and yeah | 09:55 |
| Odd_Bloke | JordanC: Are you using Olive or bzr-gtk? | 09:55 |
| JordanC | I spoke to some developers, and they said that because of the SSH factor, I can't connect to launchpad using olive | 09:55 |
| Odd_Bloke | Ah, OK. | 09:55 |
| Odd_Bloke | Have you looked at QBzr? | 09:55 |
| JordanC | Hmm, lesee | 09:56 |
| JordanC | KDE Bazaar proggy? | 09:56 |
| Odd_Bloke | JordanC: http://bazaar-vcs.org/QBzr | 09:57 |
| luks | no, in two ways | 09:57 |
| Odd_Bloke | Qt, not KDE. | 09:57 |
| luks | not a program, not kde | 09:57 |
| JordanC | Damnit | 09:57 |
| === kiko-zzz is now known as kiko | ||
| ronny | yo | 13:01 |
| ronny | is there a way to get more easy to parse output from bzr ? | 13:01 |
| ronny | (im parsing the status output for an ide, an its really tricky to get it together atm) | 13:02 |
| Odd_Bloke | ronny: There's an xmloutput plugin, I believe. | 13:22 |
| Odd_Bloke | ronny: https://edge.launchpad.net/bzr-xmloutput | 13:22 |
| Odd_Bloke | ronny: Which IDE were you thinking of? | 13:22 |
| abentley | luks: I'm looking at your patch more carefully now. | 13:22 |
| luks | thanks :) | 13:23 |
| abentley | I think a nicer way to extract the name would be to have a pattern that only matches if there's "name <email>", and if it fails to match, just return the original string. | 13:23 |
| ronny | Odd_Bloke: pida | 13:24 |
| luks | well, I think returning "email" from short_author is better than "<email>" | 13:24 |
| luks | unless you want to match "(name )?<email>", which is exactly what the patch does | 13:25 |
| abentley | I think that's highly unlikely. | 13:25 |
| ronny | Odd_Bloke: right now we parse the command output, cause the subsystem for python-api based vcs tools is basically nonexistant | 13:25 |
| luks | abentley, "<email>" is the use case from the bug report | 13:26 |
| ronny | the bad thig is - we get wrong data sometimes, but cant figure the exact source, cause the bzr output aint nice to parse (so the parser is tricky) | 13:27 |
| abentley | Also, I don't know if lazy_regex was meant to be used in new code. | 13:27 |
| abentley | I thought it was just to make existing code faster. | 13:27 |
| abentley | And I really doubt there's a performance win by using it. | 13:28 |
| luks | but what's the point of compiling a regular expession you are not going to use | 13:29 |
| luks | sure, it's not a big win, but there is a lot of small things like this | 13:29 |
| abentley | There's no win, there's loss in compiling a regular expresion. I was talking about not compiling at all. | 13:29 |
| luks | hm? you mean parsing the string manually? | 13:30 |
| abentley | no, just using re.match | 13:31 |
| luks | that compiles it every time you use it | 13:31 |
| abentley | Right. | 13:31 |
| luks | so about 3k times for log on bzr | 13:31 |
| ronny | actually its cached | 13:32 |
| abentley | luks: I really doubt that performance difference is observable. | 13:32 |
| ronny | the more often a re is used, the more sense it makes just to compile it | 13:33 |
| ronny | but the difference is only small, cause all re's u use are cached in re._cache | 13:34 |
| luks | abentley, I mean, bzrlib already has code to delay regex compilation, pre-compiled regex is faster than re.match, there is a patch that use it -- why make is slower? even if the difference is small | 13:37 |
| abentley | Because it's clearer to just write re.match | 13:37 |
| abentley | Takes fewer lines. Doesn't require people to grok lazy_regex. | 13:38 |
| ronny | hmm - how does lazy_regex work ? | 13:38 |
| luks | compiles the regex when it's first used | 13:39 |
| luks | *first time | 13:40 |
| ronny | im more intrested how the store works | 13:40 |
| ronny | cause i doubt it has any notable gain compared to re.match | 13:40 |
| abentley | ronny: It allows the "lazy_compiled" patterns to be substituted for really compiled patterns-- that's what it's for. | 13:42 |
| abentley | So you can fix import slowness without rewriting the module. | 13:42 |
| ronny | "import slowness" ? | 13:43 |
| abentley | regexes that compile at import time reduce cause latency problems for programs like Bazaar. | 13:43 |
| abentley | You run bzr, it imports a whole bunch of modules, they compile a whole bunch of regexes, and then, finally, it starts doing what you asked. | 13:44 |
| ronny | hmm - why do you guys need so many regexes ? | 13:45 |
| abentley | The libraries we import need them. | 13:45 |
| abentley | (well, they *have* them. *need* is debatable) | 13:47 |
| ronny | btw - any timeframe when bzr will be as fast as hg ? | 13:47 |
| abentley | For example ConfigObj has regexes that produce a noticeable compile delay. | 13:47 |
| abentley | ronny: It depends what you're talking about. With the packs format, commit speed is pretty similar. With the smart server, pull time is similar. | 13:48 |
| abentley | status has been comparable for some time now. | 13:49 |
| ronny | ah - so its mostly cause bzr has tonns of other operation modes ? | 13:50 |
| abentley | Well, it depends what operation you want to speed up. | 13:50 |
| ronny | all i care for is fast sync and fast commit | 13:51 |
| abentley | I think 1.0 will give you that. | 13:51 |
| ronny | hmm - i didnt exactly use bzr for quite some time | 13:52 |
| ronny | does it still try hide the existence of multiple heads (for example by allways enforcing merges) | 13:53 |
| abentley | I think we've got the pieces in place to support good performance for most commands. | 13:53 |
| abentley | I don't know what you mean by hiding the existence of multiple heads. | 13:53 |
| abentley | But in some cases, the commands must be updated to take advantage of them. | 13:54 |
| ronny | last time i used it it dodnt allowme to hae multiple heads in my repo | 13:54 |
| abentley | Repositories typically have many heads due to people uncommitting revisions. | 13:55 |
| abentley | But we don't have multiple heads for a single branch. Instead we allow multiple branches per repository. | 13:55 |
| ronny | hmmk - thats a problem for me | 13:56 |
| abentley | Why? | 13:56 |
| ronny | enforces me to split one semantical branch into multiple branches if more than one person is working on that | 13:58 |
| abentley | No, they can use heavyweight checkouts. | 13:58 |
| Odd_Bloke | ronny: That's what you're doing with multiple heads anyways... | 13:58 |
| abentley | That lets them commit locally. | 13:58 |
| abentley | And then sync up with the main branch when they're ready. | 13:59 |
| ronny | damn - how many modes of operation does bzr have ???? | 13:59 |
| abentley | We support a range from svn-like to fully distributed. | 14:00 |
| ronny | hmm - having too many choices tends to be confusing | 14:00 |
| abentley | Well, we have three: a "tree" has a branch and working copy at the same location. A "heavyweight checkout" has a branch in one location and the working copy is at different location, but has a local copy of the branch to act as cache. A lightweight checkout is like a heavyweight checkout with no local cache. | 14:04 |
| === kiko is now known as kiko-afk | ||
| === mwhudson_ is now known as mwhudson | ||
| === aosida is now known as iSoron | ||
| alecwh | I just created a bazaar branch at launchpad (https://code.launchpad.net/~alecwh/phpns/devel), and now I want to upload my project (which is in /var/www/devel) to the repository. In the terminal, my working directory is /var/www/devel, and I gave the command: bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel , but it doesn't seem to be working. I get the error: bzr: ERROR: Not a branch: /var/www/devel/ , can anyone help me upload | 19:28 |
| luks | cd /var/www/devel; bzr init; bzr add; (check if it added only files you want); bzr commit | 19:29 |
| luks | and then you can use bzr push | 19:30 |
| luks | http://doc.bazaar-vcs.org/bzr.0.92/en/mini-tutorial/index.html#putting-files-under-version-control | 19:30 |
| alecwh | ok, I'll try that. will 'bzr add' add every single directory and file inside /var/www/devel? | 19:31 |
| lifeless | moin | 19:31 |
| alecwh | moin? | 19:31 |
| lifeless | alecwh: yes, add adds recursively, obeying your ignore rules | 19:35 |
| alecwh | thanks lifeless. I've got one more question: when I was using svn, every 'commit' you made actually uploaded your changes to the online repository. Is this not the case with bazaar? | 19:36 |
| lifeless | alecwh: if you have a checkout it acts like svn | 19:37 |
| alecwh | a checkout? | 19:38 |
| lifeless | alecwh: that is, if you do 'bzr checkout bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel local-dir-name' | 19:38 |
| lifeless | then you can cd local-dir-name, and do | 19:38 |
| alecwh | that will download the project, right? | 19:38 |
| lifeless | 'bzr commit', which will commit back to bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, just like svn | 19:38 |
| alecwh | oh. | 19:38 |
| beuno | alecwh, or, when you want to send all your commits, just use "bzr push" | 19:39 |
| lifeless | alecwh: if you have a separate 'branch' though, then your commits are performed just on your machine | 19:39 |
| alecwh | ok, that makes sense. | 19:39 |
| alecwh | https://code.launchpad.net/~alecwh/phpns/devel | 19:39 |
| beuno | (when using branches instead of checkouts) | 19:39 |
| alecwh | I just finished uploading everything... | 19:39 |
| lifeless | alecwh: and then when you want them to be in bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel, you do 'bzr push bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel' (bzr will remember the push location the first time, so you don't need to type it every time0 | 19:39 |
| alecwh | how do I make it so every time I 'commit' it will update this repository? | 19:40 |
| lifeless | alecwh: bzr bind bzr+ssh://alecwh@bazaar.launchpad.net/~alecwh/phpns/devel | 19:40 |
| alecwh | ok lifeless, that worked. =D | 19:40 |
| alecwh | I was using 'cia.vc', which puts a bot inside your channel on freenode, and then it will post a message inside the channel whenever a commit/change is made. Is there something like this for bazaar? | 19:41 |
| lifeless | alecwh: there is a plugin for bzr to announce to cia | 19:42 |
| lifeless | alecwh: you can also subscribe to the branches on launchpad | 19:42 |
| lifeless | alecwh: or install bzr-email to send emails to arbitrary email address's on commits | 19:42 |
| alecwh | ok, cool. Do you know what the plugin was called? I'm just looking for it... | 19:43 |
| lifeless | http://www.google.com/search?q=bzr+cia&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a | 19:44 |
| lifeless | 3rd and 4th hits look relevant to me | 19:44 |
| alecwh | https://launchpad.net/bzr-cia | 19:46 |
| alecwh | lifeless, uhm, how do I get the plugin? =P | 19:50 |
| beuno | alecwh, with bzr, of course :D | 19:51 |
| alecwh | https://code.launchpad.net/~jelmer/bzr-cia/main | 19:52 |
| alecwh | is this the one I'm looking for? | 19:52 |
| beuno | alecwh, yeap | 19:52 |
| alecwh | bzr branch http://bazaar.launchpad.net/~jelmer/bzr-cia/main? | 19:52 |
| alecwh | use that command? | 19:52 |
| beuno | alecwh, yeah, you download it with that command | 19:53 |
| alecwh | ok, done. =D | 19:53 |
| alecwh | I think I got it now | 19:53 |
| beuno | now, follow the instructions in: https://launchpad.net/bzr-cia | 19:53 |
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| === me_too is now known as turbo0O | ||
| === turbo0O is now known as me_too | ||
| === me_too is now known as too_short | ||
| === too_short is now known as me_too | ||
| === adib is now known as theAdib | ||
| lifeless | success; we have a 1.0 build on dapper-amd64 | 22:17 |
| lifeless | i386 testing now | 22:17 |
| lifeless | brb foodstuff time | 22:17 |
| === mwhudson_ is now known as mwhudson | ||
| dato | jelmer: very well | 22:34 |
| dato | jelmer: btw, I guess there is no way to convert from svn a trunk and a branch, if I somehow say which revisions from the trunk are merges from the branch, right? | 22:35 |
| jelmer | dato: only if you can go back in history and set some magic svn properties | 22:40 |
| dato | jelmer: can I a dump of the repository, load it locally, set the properties there, and redump? that ought to work? | 22:40 |
| jelmer | dato: yes, but you would want to change the uuid | 22:42 |
| dato | ok. is there a document explaining what properties I should set? | 22:42 |
| jelmer | and pulling from the original in the future may be problematic | 22:43 |
| jelmer | http://bazaar-vcs.org/BzrForeignBranches/Subversion/mapping | 22:43 |
| jelmer | basically, you'd want to set the bzr:ancestry:vX-SCHEME property | 22:46 |
| lifeless | dato: is it really worth doing? why not just do a merge after the conversion? | 22:47 |
| dato | jelmer: it's a one-time conversion | 22:47 |
| dato | lifeless: I seem to find a strange pleasure fiddling with the tools. | 22:48 |
| lifeless | dato: :) | 22:49 |
| dato | jelmer: ok, thanks for the link. I'll try to do it. also, I svn-import trunk didn't work for me yesterday, but the packaged version worked fine. I'll try again tomorrow. finally ;), changing the UUID is just a matter of editing the dumpfile by hand, or? | 22:53 |
| jelmer | dato: the trunk branch for bzr-svn is highly experimental | 23:08 |
| jelmer | dato: 0.4 is the branch that is packaged | 23:08 |
| jelmer | dato: yep, editing the dumpfile should be all that's needed to change the uuid | 23:09 |
| abentley | lifeless: What do you consider a good way to decide if something should be a separate module or not? | 23:09 |
| abentley | I was expecting plan_merge to be bigger than it is, which is why I originally did it. | 23:11 |
| lifeless | abentley: I don't have a good rule; sometimes I get there and combine; sometimes I start in the same module and split. | 23:11 |
| vila | wtf ? test_revision.TestIsAncestor.test_is_ancestor is failing just under the comment: | 23:13 |
| vila | # NB: if you see an assertion error here, its probably access against | 23:13 |
| vila | # an unlocked repo. Naughty. | 23:13 |
| abentley | I guess by analogy, I'd think if merge3 has its own module, then annotate merge can have one, too. | 23:13 |
| vila | the problem is I'm working on http response parsing rewrite and I can't find any link >-/ | 23:14 |
| vila | Worse, the same test on bzr.dev@3059 fails too, midnight bug ? | 23:15 |
| vila | and on top of that, I see (when doing bzr missing in my bzr.dev branch) revno: 3061, deprecate bzrlib.revision.is_ancestor | 23:16 |
| vila | Ran 9939 tests in 437.020s | 23:18 |
| vila | FAILED (failures=1, known_failure_count=5) | 23:18 |
| vila | bah, time to sleep anyway, a bit frustrating though | 23:19 |
| vila | not failing anymore in bzr.dev@3065... at least.... | 23:21 |
| lifeless | jelmer: where is bzr-gtk for 1.0 ? | 23:27 |
| lifeless | abentley: oh it can have one if you think it should; I was asking the question. | 23:30 |
| abentley | Sure, and I've actually decided to move them into versionedfile and merge. | 23:31 |
| abentley | Just because there's so much related stuff in those modules. | 23:31 |
| jelmer | lifeless: phanatic is doing release management these days, I'll ping him by email | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!