| jml | grats on the release! | 00:01 |
|---|---|---|
| jam | jml: thanks | 00:11 |
| ronny | bob2: thanks | 00:13 |
| jam | lifeless: with my "add_node" update and my "single-pass" update to btrees, it is actually faster to write out a btree index of my mysql repo than it is to *read* (_buffer_all) the graph index | 00:36 |
| lifeless | nice work | 00:36 |
| jam | 36s to 28s | 00:36 |
| jam | s/to/vs/ | 00:37 |
| lifeless | you have quite a knack for micro-tuning | 00:37 |
| lifeless | has any of the btree stuff landed in dev yet? | 00:37 |
| jam | lifeless: The initial btree code has landed | 00:39 |
| jam | none of my follow up patches | 00:39 |
| jam | There are 2 right now, but one is superseded once I finish this benchmark run | 00:40 |
| lifeless | ok | 00:41 |
| === mario_ is now known as pygi | ||
| === mark1 is now known as markh | ||
| * mwhudson points at 6895 | 00:54 | |
| mwhudson | no | 00:54 |
| * mwhudson points at https://bugs.edge.launchpad.net/bzr/+bug/261315 | 00:54 | |
| ubottu | Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Undecided,New] | 00:54 |
| === mw is now known as mw|out | ||
| muntyan | could someone help me fix this error on fast-import: bzr: ERROR: Bad repository size - 3639 revisions found, 3637 expected | 01:51 |
| muntyan | i imorted a hg repo using fast-import, all was good; but then i committed a change in the bzr repo and now i get that error when trying to use fast-import again | 01:52 |
| muntyan | and i got to fix this bzr repo because i pushed it to yet another remote location, so i can't just throw it away and convert the mercurial repo again | 01:52 |
| bob2 | isn't fast-import only for one-shot imports? | 01:53 |
| muntyan | no, it seems to work fine for synchronizing | 01:54 |
| muntyan | but apparently you must not touch the bzr reop in between | 01:54 |
| muntyan | here: As long as the fastimport-id-map file is not deleted and the front-end generates an export which begins with the same content as the previous import, bzr-fastimport can be used to maintain a Bazaar mirror of a foreign repository. | 01:55 |
| bob2 | can you branch your broken trunk, from a couple of revs back to new-trunk, and continue th import against that? | 01:56 |
| muntyan | i can, but the problem is that it breaks my push to remote repo | 01:57 |
| muntyan | so i need to fix this bzr repo in-place | 01:57 |
| muntyan | i think | 01:57 |
| bob2 | what breaks your push? | 01:57 |
| muntyan | err, nevermind | 01:57 |
| muntyan | i didn't try that indeed | 01:57 |
| fullermd | Erm. Hm. This is odd... | 02:01 |
| fullermd | lifeless: ping | 02:06 |
| lifeless | yo | 02:08 |
| fullermd | If I can pull a --long --strict testment of a revision, that means the revision is present and accounted for, right? | 02:08 |
| lifeless | EPARSE | 02:09 |
| fullermd | OK, I've got this knit branch, that I need to de-knit now that we're on 1.6. | 02:09 |
| rocky | jelmer: don't suppose you worked on the speed stuff anymore for 0.4.11 ? | 02:09 |
| jelmer | rocky, It should've improved quite a bit | 02:09 |
| fullermd | I have 3 different repos with it, on 2 different boxes. All of them 'check' just fine. All of them, though, blow up on upgrade claiming a given rev is not present in "<bzrlib.knit.KnitVersionedFiles object at 0x89e3fec>". | 02:10 |
| rocky | jelmer: oh? so i should try again? | 02:10 |
| jelmer | rocky, yeah, please do | 02:10 |
| fullermd | I can pull the testament of that rev fine, though. It's right there in log. diff -c is right. | 02:10 |
| rocky | jelmer: i'm sitting on dial-up this very second so i'll have to be creative ;) | 02:10 |
| fullermd | reconcile doesn't do anything to help | 02:10 |
| lifeless | fullermd: testaments don't access filecontents | 02:10 |
| lifeless | fullermd: whats the missing rev? | 02:10 |
| lifeless | also, pastebin your check output | 02:11 |
| fullermd | What in what sense? The revid? | 02:11 |
| lifeless | fullermd: it will have printed a tuple | 02:12 |
| lifeless | fullermd: whats the tuple; also, what is the output of check | 02:12 |
| fullermd | What pastebin is it you can reach well? | 02:12 |
| lifeless | all these days, ipv6 tunnel is repaired | 02:13 |
| fullermd | lifeless: http://pastebin.com/m5908d8d6 | 02:15 |
| fullermd | Testament pulls the rev fine, as does diff'ing, or cat'ing the file it changes. | 02:15 |
| lifeless | fullermd: testament doesn't mean jack | 02:15 |
| lifeless | fullermd: it just means 'can read the inventory' | 02:15 |
| fullermd | Well, what is there to the rev aside from the inventory and log message and timestamp and yada yada, and how can I access it other than via 'upgrade'? | 02:16 |
| lifeless | that tuple is a single revid, so its either a revision or an inventory issue | 02:16 |
| rocky | jelmer: should i get the bzr 0.4 branch or try the latest 0.4.11 rc ? | 02:17 |
| lifeless | or a signature | 02:17 |
| fullermd | No signatures, so that part's clear. | 02:17 |
| lifeless | fullermd: bzr 1.6 ? | 02:17 |
| jelmer | rocky, there's only one rc :-) | 02:17 |
| fullermd | 1.6 and bzr.dev | 02:17 |
| rocky | oh | 02:17 |
| jelmer | rocky, you need th 0.4 branch | 02:17 |
| rocky | gotcha | 02:17 |
| lifeless | fullermd: ok, in python | 02:17 |
| lifeless | import bzrlib.repository | 02:17 |
| lifeless | r = bzrlib.repository.Repository.open('...') | 02:18 |
| lifeless | r.lock_read() | 02:18 |
| lifeless | r.revisions.get_parent_map([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)]) | 02:18 |
| fullermd | {('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',): (('fullermd@over-yonder.net-20080425022841-hkrtkho705s4m5hr',),)} | 02:19 |
| lifeless | r.inventories.get_parent_map([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)]) | 02:19 |
| fullermd | {('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',): (('fullermd@over-yonder.net-20080425022841-hkrtkho705s4m5hr',),)} | 02:20 |
| lifeless | r.signatures.get_parent_map([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)]) | 02:20 |
| fullermd | {} | 02:20 |
| lifeless | list(r.revisions.get_record_stream([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)], 'topological', True)) | 02:22 |
| fullermd | [<bzrlib.versionedfile.FulltextContentFactory object at 0x8a365ec>] | 02:22 |
| lifeless | list(r.inventories.get_record_stream([('fullermd@over-yonder.net-20080425023244-ka60gfoa446hlc8m',)], 'topological', True)) | 02:22 |
| fullermd | [<bzrlib.versionedfile.FulltextContentFactory object at 0x8a3ac2c>] | 02:23 |
| lifeless | ok | 02:24 |
| lifeless | emystified | 02:24 |
| lifeless | try running the upgrade with BZR_PDB=1 | 02:24 |
| fullermd | The upside is that it does out pretty quick at least... | 02:25 |
| fullermd | 'k | 02:25 |
| fullermd | > /home/fullermd/src/bzr/bzr.dev/bzrlib/knit.py(229)get_bytes() | 02:25 |
| fullermd | -> raise errors.RevisionNotPresent(compression_parent, self._basis_vf) | 02:25 |
| lifeless | print basis_entry | 02:26 |
| fullermd | <bzrlib.versionedfile.AbsentContentFactory object at 0x8dbca0c> | 02:26 |
| lifeless | print self._basis_vf | 02:26 |
| fullermd | <bzrlib.knit.KnitVersionedFiles object at 0x8aac7ec> | 02:27 |
| lifeless | print self._basis_vf._index | 02:27 |
| lifeless | print self._basis_vf._access | 02:27 |
| fullermd | _KnitGraphIndex(CombinedGraphIndex()) | 02:27 |
| fullermd | <bzrlib.knit._DirectPackAccess object at 0x8aac62c> | 02:27 |
| lifeless | you're upgrading from knits | 02:27 |
| lifeless | ? | 02:27 |
| * fullermd nods. | 02:28 | |
| lifeless | ok, wtf | 02:28 |
| lifeless | uhm, bt ? | 02:28 |
| fullermd | http://pastebin.com/m2efbcdf1 | 02:28 |
| lifeless | up | 02:29 |
| lifeless | print adapter_key | 02:30 |
| rocky | jelmer: new traceback :( | 02:30 |
| jelmer | rocky, please pastebin | 02:30 |
| fullermd | (I'm on 3644 of bzr.dev btw; think I'm a day or two back, if it matters) | 02:30 |
| fullermd | ('knit-delta-gz', 'fulltext') | 02:30 |
| lifeless | ok | 02:31 |
| lifeless | so we got a knit-delta-gz | 02:31 |
| lifeless | print record.storage_kind not in native_types: | 02:31 |
| lifeless | erm | 02:31 |
| lifeless | print record.storage_kind not in native_types | 02:31 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/803 | 02:31 |
| fullermd | True | 02:32 |
| lifeless | print native_types | 02:32 |
| fullermd | set(['knit-ft-gz']) | 02:32 |
| rocky | jelmer: this time it's svn 1.4, bzr 1.6 (final), and bzr-0.4 branch | 02:32 |
| lifeless | ok | 02:32 |
| lifeless | thats truely bizaare | 02:32 |
| lifeless | I know whats happening | 02:32 |
| fullermd | My specialty 8-} | 02:32 |
| lifeless | please file a bug, I'll comment on it | 02:32 |
| lifeless | you have a revision record which is a delta | 02:32 |
| lifeless | we're not meant to delta revisions | 02:33 |
| fullermd | OK. That rev would have been made with bzr.dev of around the timestamp of the rev (T-0 to a few days behind) | 02:33 |
| jelmer | rocky, one sec, I'll add another assertion | 02:34 |
| lifeless | still, we can fix by asking for revisions in topological order | 02:34 |
| jelmer | rocky, please try again with r1657 | 02:34 |
| lifeless | whats failing is that the revision *after* the one the error shows is a delta, and the one the error shows has not been copied yet | 02:34 |
| === rocky1 is now known as rocky | ||
| rocky | jelmer: sorry, disconnected, did you see my pastebin paste? | 02:35 |
| jelmer | rocky, yep | 02:36 |
| jelmer | rocky, any chance you can try again with r1657? | 02:36 |
| fullermd | bug 261339 | 02:36 |
| ubottu | Launchpad bug 261339 in bzr "Upgrade from knit to pack fails on revision not present" [Undecided,New] https://launchpad.net/bugs/261339 | 02:36 |
| jelmer | rocky, it should give a better indication of what's wrong now | 02:36 |
| rocky | jelmer: yep | 02:36 |
| muntyan | it's not my commits, hg-fast-export.py | bzr fast-import simply doesn't work more than once! | 02:38 |
| fullermd | Well, that's neat. Usually, I only break dirstate; I've never done revisions before. | 02:39 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/804 | 02:39 |
| muntyan | is it possible to import a changeset, i.e. have a patch automatically applied and committed? | 02:43 |
| jelmer | rocky, please try r1658 | 02:44 |
| rocky | tsk tsk ... someone's not running their unit tests... :) | 02:46 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/602 ;) | 02:46 |
| lifeless | muntyan: you can script that obviously | 02:48 |
| jelmer | argh, another 1.4/1.5 inconsistency | 02:48 |
| jelmer | rocky, please try yet again :-) | 02:49 |
| jelmer | r1659 | 02:49 |
| rocky | jelmer: http://cluebin.appspot.com/pasted/603 | 02:51 |
| jelmer | argh | 02:52 |
| jelmer | thanks for testing with svn 1.4 :-) | 02:52 |
| jelmer | please try again :-) | 02:52 |
| rocky | lol | 02:52 |
| rocky | no revisions to pull | 02:52 |
| jelmer | r1660 | 02:53 |
| jelmer | it should be pushed | 02:53 |
| rocky | that got it | 02:53 |
| jelmer | you'll have to run make again | 02:56 |
| rocky | jelmer: it committed my file that time... and it was quite fast ... but unfortunately it's not a very good speed test from me because the only remote http+svn server i have to test against is the only server i can actually test bzr on (ie the commits are going to the local box through http+svn) | 02:56 |
| rocky | i can see that it still made a ton of requests | 02:56 |
| jelmer | rocky, how much is a ton ? | 02:57 |
| rocky | checking | 02:59 |
| rocky | jelmer: my apache log shows 164 requests for a commit of one empty text file | 02:59 |
| rocky | jelmer: would it help if i gave you a svn dump of that repo? you could test commits against it yourself? | 03:01 |
| jelmer | it's still doing the checks of all paths | 03:01 |
| jelmer | there's just some other things that have improved performance | 03:01 |
| jelmer | rocky, Have you compared this to doing a similar commit with Subversion? | 03:04 |
| rocky | jelmer: no? didn't think that would be terribly relevant | 03:04 |
| jelmer | rocky: Any chance you can try running the bzr commit with -Dtransport ? | 03:05 |
| jelmer | That should write the high level svn operations to ~/.bzr.log | 03:05 |
| rocky | sure | 03:05 |
| jelmer | there are several svn operations that translate into multiple http requests | 03:06 |
| jelmer | I bet svn itself does also requires a significant amount of http requests | 03:06 |
| rocky | i'm pretty sure it doesn't actually | 03:06 |
| rocky | several per commit | 03:06 |
| rocky | jelmer: the log appears huge | 03:09 |
| rocky | jelmer: http://paste.plone.org/23383 | 03:11 |
| jelmer | rocky, only r1030 is from the last run | 03:12 |
| rocky | ah | 03:12 |
| jelmer | rocky, the log output doesn't look too bad | 03:13 |
| muntyan | is there a command to remove files which are deleted on disk? like 'bzr add' but for removed files | 03:52 |
| lifeless | bzr rm | 03:53 |
| bob2 | they'll be removed when you commit, if they are no longer on disk | 03:53 |
| lifeless | I don't know if the automatic version is in 1.6, its definitely in bzr.dev | 03:53 |
| lifeless | you can just type 'bzr rm' and any absent files are removed | 03:53 |
| muntyan | lifeless: ERROR: Specify one or more files to remove, or use --new. | 03:54 |
| muntyan | bob2: cool, thanks | 03:54 |
| lifeless | muntyan: right, only bzr.dev then | 03:56 |
| nmb | I'm working on bug 239523 and I've got a question about how bzr uses stdout and stderr...Anyone here have any opinions? | 04:03 |
| ubottu | Launchpad bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed] https://launchpad.net/bugs/239523 | 04:03 |
| mwhudson | abentley: ah, i'm glad you've seen the default_stacked_on mess thread... | 04:13 |
| Verterok | nmb: what is your question? (I'm not an expert, but I'll try to help :) | 04:20 |
| nmb | Verterok: Currently, messages like "Now on revision 2." when you pull go to stdout and status information like """M file | 04:21 |
| nmb | All changes applied successfully.""" | 04:21 |
| nmb | goes to stderr. | 04:21 |
| nmb | In order to make all of the commands obey the --quiet option, I want to use the logging framework to print messages like "Now on revision 2". But the way it is currently set up, if we use the logging framework we go to stderr. | 04:22 |
| lifeless | nmb: we send messages with the response to the users query to stdout | 04:23 |
| nmb | So I guess my question is: should all informational messages go to one stream? | 04:23 |
| lifeless | nmb: and messages about progress/general chatter/progress bars to stderr | 04:23 |
| nmb | lifeless: then does bzrlib.trace need to grow a new function in addition to note() that writes to stdout? | 04:24 |
| lifeless | nmb: why? | 04:24 |
| lifeless | std out is on self.outf on command objects, thats where it should be | 04:24 |
| nmb | Because the current way of getting there, self.outf.write, doesn't respect --quiet | 04:24 |
| Verterok | nmb: in the commands you have access to self.outf/to_file | 04:24 |
| lifeless | nothing should be writing to sys.stdout anywhere in the code base | 04:24 |
| lifeless | because that may not be encoded correctly | 04:24 |
| Verterok | nmb: commands should check trace.is_quiet() (If I remember ok) | 04:25 |
| nmb | Verterok: that's very ugly with lots of "if trace.is_quiet()"s appearing in builtins.py. It seems like it is screaming for a function that does exactly that. | 04:26 |
| Verterok | nmb: is_quiet() or not is_quiet() is passed to the method/function that do the real work | 04:28 |
| nmb | Verterok: that's not what I see. For example, if not is_quiet(): | 04:29 |
| nmb | self.outf.write("Using saved parent location: %s\n" % display_url) | 04:29 |
| lifeless | well, global state is bad | 04:30 |
| lifeless | more global state referring functions is more bad | 04:30 |
| lifeless | I could see a method on Command | 04:31 |
| nmb | lifeless: It seemed that when Ian made --quiet a global option we assented to the existence of global state information... | 04:31 |
| * Verterok was looking to cmd_add | 04:32 | |
| nmb | currently we refer to that global state in lots of different places when we need to make sure that we obey the option... | 04:32 |
| lifeless | nmb: We can always improve the quality of the code base | 04:32 |
| lifeless | 'we do it this way currently' just means that we have code we can learn from. | 04:33 |
| nmb | I think it's cleaner if we refer to that global state in a central location, so that callers simply need to say "I would like to tell the user X" | 04:33 |
| nmb | and the global state controls how that telling works. | 04:33 |
| lifeless | So, remove the global state | 04:33 |
| Verterok | nmb: something like logging levels? | 04:33 |
| lifeless | ugh no no no, python logging is nuts | 04:34 |
| nmb | Verterok: --quiet is implemented with logging levels | 04:34 |
| nmb | See trace.py for the gory details. | 04:35 |
| Verterok | nmb: ok, I get it now | 04:36 |
| nmb | If I talk out loud about what would be ideal... | 04:36 |
| nmb | It seems we need some global state in order for --quiet to apply globally... | 04:36 |
| lifeless | I'll repeat my design input - less global state is massively preferred. | 04:37 |
| nmb | I'll agree with that as a design principle...any ideas on how to implement a global option without having to pass around is_quiet options to everything that does output? | 04:38 |
| lifeless | self.outf on command objects is already non-global, I'm extremly strongly against making it global, or causing it to be used globally by requiring global state for it to work well | 04:38 |
| lifeless | I suggested a method on Command before | 04:39 |
| nmb | Hmmm. Where does one get an actual instance of Command where one could set the self._quiet attribute so that a method self.feedback could respect it? | 04:40 |
| lifeless | nmb: its created by the setup code for running the command - the same stuff that parses options and detects -q | 04:40 |
| markh | when would changes_from be preferred over iter_changes (or vice-versa)? | 04:41 |
| lifeless | markh: iter_changes is generally preferred; changes_from is implemented on iter_changes | 04:41 |
| Verterok | nmb: commands.run_bzr | 04:41 |
| lifeless | markh: but if you need a in memory delta, changes_from is that | 04:41 |
| lifeless | nmb: I would start just by having the code you want on Command | 04:42 |
| markh | I think we just need simple status to build a listbox of "modified" items, for example. Current code uses changed_from, but iter_changes has a better api | 04:42 |
| nmb | Verterok: got it, get_cmd_object, etc. | 04:42 |
| markh | (its in qbzr) | 04:42 |
| lifeless | nmb: don't duplicate state - that is don't have a _is_quiet that is separate from the current is_quiet state, because that allows skew | 04:42 |
| lifeless | nmb: instead, refer to the current state, but from a non-global location; then we can work on reducing the global stuff separately | 04:43 |
| lifeless | markh: then use iter_changes | 04:43 |
| nmb | lifeless: makes sense, two steps | 04:43 |
| markh | I will, thanks :) | 04:43 |
| lifeless | :) | 04:43 |
| nmb | off to hack, thanks all | 04:43 |
| mwhudson | hmm | 05:29 |
| mwhudson | i'm writing a test involving remote branches and the test runner is complaining about threads being left behind | 05:30 |
| mwhudson | they seem to be smart server 'connection threads' | 05:30 |
| mwhudson | hnnh, dropping the branch objects and running gc.collect() makes the message go away | 05:31 |
| lifeless | branch objects hold transports, transports hold sockets, sockets hold servers | 05:36 |
| mwhudson | and there is no transport.close | 05:37 |
| lifeless | right | 05:37 |
| lifeless | even if there was, you'd be breaking the branch object state | 05:37 |
| mwhudson | well yes | 05:38 |
| lifeless | bzr tests clean their state during tearDown | 05:39 |
| lifeless | perhaps you're not tearing down | 05:39 |
| mwhudson | no, i am | 05:39 |
| mwhudson | lifeless: here's my TestCase: http://pastebin.ubuntu.com/40570/ | 05:40 |
| mwhudson | (which is more complicated than i would like in at least two ways...) | 05:41 |
| lifeless | line 4 can be in the body | 05:43 |
| mwhudson | oh right yes | 05:44 |
| lifeless | oh I see | 05:45 |
| lifeless | so, theres probably a cycle in there or something | 05:45 |
| lifeless | and python gc ftl | 05:45 |
| mwhudson | well | 05:48 |
| mwhudson | i don't think there are any gcs that do prompt collection of cycles | 05:48 |
| mwhudson | lifeless: i also don't really get why make_branch isn't returning a RemoteBranch | 05:49 |
| lifeless | you haven't set a format | 05:49 |
| lifeless | so you're making a default format branch on a VFS that happens to be remote | 05:50 |
| mwhudson | ah | 05:50 |
| mwhudson | lifeless: http://pastebin.ubuntu.com/40573/ | 05:56 |
| mwhudson | lifeless: ^ saner, by your book? | 05:56 |
| lifeless | uh | 05:58 |
| lifeless | self.make_branch('.') is cleaner | 05:59 |
| mwhudson | well, that creates a BzrBranch on a RemoteTransport (i think...) | 06:02 |
| mwhudson | seems a slightly strange beast | 06:02 |
| mwhudson | but sure, it works | 06:02 |
| lifeless | A RemoteTransport is a Transport | 06:02 |
| mwhudson | true enough | 06:03 |
| Verterok | mwhudson: I started hacking on Bug #243415 | 06:06 |
| ubottu | Launchpad bug 243415 in loggerhead "Tracebacks go to console but not log file" [Medium,Confirmed] https://launchpad.net/bugs/243415 | 06:06 |
| mwhudson | Verterok: oh cool | 06:06 |
| Verterok | mwhudson: I already have a working wsgi middleware to log the tracebacks | 06:07 |
| Verterok | do you have any particular idea on this topic? | 06:08 |
| mwhudson | Verterok: nope, that sounds sane, generally speaking | 06:08 |
| mwhudson | Verterok: for the one on launchpad we want to do Something Else (tm) with unhandled exceptions, so middleware makes sense | 06:09 |
| mwhudson | (we'll just use our own, rather than whatever you write that ends up in loggerhead itself) | 06:09 |
| Verterok | mwhudson: ok, ATM it's just log the error and shows the traceback to the user :P (now trying to figure out how to use a template to show a nice message to the user) | 06:10 |
| mwhudson | it could be a little awkward because loggerhead streams it's output | 06:10 |
| mwhudson | if the error happens after the headers have been sent, there's a limit to what you can do | 06:11 |
| Verterok | mmm, I see | 06:11 |
| Verterok | so, adding a fallback (standalone) template/html should do the trick | 06:12 |
| Verterok | ah, adding launchpad specific magic should be fairly easy, just overriding loggerhead.apps.error_app ;) (that's the idea) | 06:12 |
| * mwhudson gives his wireless a good kicking | 06:35 | |
| markh | In http://bazaar-vcs.org/Integrating_with_Bazaar, it says about smart_add: "Paths can either be absolute or relative to the workingtree". Does this mean that even if the cwd() isn't in the tree, relative path names should still be taken as if they are from the root of the tree? | 08:22 |
| markh | cos if it does, I think I can demonstrate it doesn't work :) | 08:22 |
| lifeless | uhm | 08:24 |
| lifeless | smart_add needs a path from cwd into the tree | 08:24 |
| lifeless | its an API buglet | 08:24 |
| markh | worth reporting a bug, or just work around it? :) | 08:25 |
| markh | well - *and* work around it ;) | 08:26 |
| lifeless | no | 08:26 |
| lifeless | either a patch to fix it | 08:26 |
| lifeless | or not :) | 08:26 |
| markh | well, I could see it being ambiguous. If the cwd is *inside* the tree, should a relative name still be from the root? | 08:27 |
| lifeless | tree apis should not depend on cwd | 08:27 |
| lifeless | thats the bug | 08:27 |
| lifeless | cwd is bad and fragile | 08:28 |
| markh | yeah - today a relative name is taken from the cwd. So that could break peoples code? | 08:28 |
| lifeless | on some platforms its not thread safe | 08:28 |
| lifeless | markh: yes, it would break peoples code to change it | 08:28 |
| markh | but it would still be approved you think? | 08:28 |
| markh | (btw - I resurrected the branch that allows 'bzr up -r' too :) I hope it doesn;t languish...) | 08:29 |
| lifeless | markh: I'd review a fix to smart_add | 08:31 |
| lifeless | probably want to rename+deprecate to provide a transition path | 08:31 |
| markh | how about one for 'up -r'? ;) | 08:35 |
| lifeless | I'd like to fix the double-merge bug first | 08:40 |
| lifeless | so that it stops if the first merge conflicts | 08:40 |
| lifeless | I think cleaning that up will make the overall code cleaner | 08:40 |
| === arjenAU2 is now known as arjenAU | ||
| === Spaz is now known as ^_- | ||
| lifeless | morning visik7 | 09:36 |
| lifeless | erm sorry | 09:36 |
| lifeless | I mean vila | 09:36 |
| em1 | hi | 09:36 |
| lifeless | damn completion bugs | 09:36 |
| lifeless | hi em1 | 09:36 |
| vila | hi robert :) | 09:36 |
| visik7 | ola lifeless | 09:53 |
| visik7 | asd | 09:53 |
| visik7 | typo | 09:53 |
| lifeless | :P | 09:55 |
| lifeless | jam: :( AssertionError: Somehow we ended up with too much compressed data, 4012 > 3976 | 10:25 |
| lifeless | jam: I'd like to make that impossible. | 10:25 |
| em1 | AttributeError: 'module' object has no attribute 'symlink' | 10:30 |
| em1 | why? | 10:30 |
| james_w | em1: are you on windows? | 10:30 |
| gour | em1: have you fetched that openerp sources? | 10:31 |
| gour | james_w: he was on xp last time | 10:32 |
| james_w | then without more context I would guess that it is bug 81689 | 10:34 |
| ubottu | Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Confirmed] https://launchpad.net/bugs/81689 | 10:34 |
| em1 | yes | 10:36 |
| em1 | im on windows and fetching openerp source | 10:37 |
| gour | cool ;) | 10:37 |
| em1 | how to fix this bug? | 10:37 |
| em1 | or i can ignore this error ? | 10:37 |
| lifeless | em1: get the windows symlink plugin | 10:38 |
| em1 | how to get, lifeless? | 10:38 |
| gour | em1: or use windows less often :-) | 10:38 |
| em1 | gour, which linux disto is better? | 10:39 |
| lifeless | than windows? Any | 10:40 |
| gour | em1: i'm running arch linux (http://www.archlinux.org/), but if you're new with linux i recommend ubuntu | 10:40 |
| lifeless | em1: http://bazaar-vcs.org/BzrPlugins | 10:40 |
| em1 | but, after all, window is used for years | 10:42 |
| gour | moving to linux will be like liberation from the prison :-) | 10:44 |
| luks | if you get used to the crashing apps :) | 10:45 |
| em1 | im afraid of linux is another prison, lol | 10:45 |
| em1 | 'No download files exist for this project. ' | 10:45 |
| gour | ?? | 10:47 |
| em1 | seems that no files can been download to install at that site | 10:47 |
| lifeless | what site | 10:47 |
| em1 | https://launchpad.net/bzr-win32symlinks | 10:47 |
| em1 | gour, you still know me and last time on windowsxp, good enough | 10:48 |
| lifeless | em1: click on code | 10:49 |
| gour | em1: https://code.launchpad.net/bzr-win32symlinks | 10:49 |
| gour | em1: same as with openerp ;) | 10:49 |
| em1 | got it, thank all | 10:49 |
| gour | em1: don't forget to switch to (ubuntu) linux ;) | 10:51 |
| em1 | yes, must do after finishing work on hand | 10:51 |
| gour | ok. cool. see you then in some #linuxdistro :-) | 10:52 |
| em1 | ok, you are there waiting my question | 10:52 |
| gour | :-) | 10:53 |
| gour | em1: download something like free Virtualbox plus e.g. Ubuntu CD and try installing it under XP | 10:56 |
| em1 | ok, i will try | 10:57 |
| gour | em1: what kind of apps you use on xp? | 10:59 |
| em1 | gour, im developing a erp project and a voip project | 11:10 |
| em1 | two proj all be huge enough , so i dare not conver into linux at once | 11:11 |
| em1 | after all, both are java project | 11:11 |
| em1 | downloading openerp is just for fun or study | 11:13 |
| gour | ahh, java isn't multi-platform :-) | 11:13 |
| em1 | i feel svn is good enough, but met bzr, have to try it. | 11:14 |
| em1 | gour, it is said that java is cross-platform | 11:15 |
| gour | bzr is definitely better and you can use bzr-svn if you need to work on svn repos | 11:15 |
| gour | em1: then you can install linux to test your app there ;) | 11:16 |
| em1 | basiclly, java app need not test under kinds of os | 11:17 |
| lifeless | em1: actually, VM differences mean you do | 11:18 |
| lifeless | em1: IME | 11:19 |
| em1 | lifeless, what means IME? | 11:20 |
| lifeless | in my experience | 11:20 |
| em1 | good, ime, at end, when want to deploy it, i will test it, | 11:21 |
| em1 | at end stage | 11:21 |
| em1 | at develop stage, no more time to test over and over in other platform | 11:22 |
| thumper | Odd_Bloke: ping | 11:36 |
| james_w | thumper: I think he started his job today | 11:38 |
| thumper | james_w: ah, ok, thanks | 11:38 |
| cammoblammo | I have a set of changes I want to make to a file versioned with bzr, but down the track I'm going to want to revert to it's original form. However, I'll still want to be able to have access to the changed file if needed. Is there a magic way of swapping between lines of development, or is it easiest to simply copy the file to a different location and treat it separately? | 12:10 |
| lifeless | cammoblammo: yes, we call it branching :) | 12:21 |
| cammoblammo | I thought that might be the way to go. I've never used VC for anything other than strictly linear work. Looks like I have some reading to do! | 12:26 |
| === gour is now known as gour|lunch | ||
| em1 | got to go, by all | 12:43 |
| jam | lifeless: is that with existing btree or with my updates? My new predictor is much less susceptible to it | 13:00 |
| jam | It uses an estimated compression of "1" and then updates that as we SYNC | 13:00 |
| jam | so all new bytes are assumed to not compress until we sync | 13:00 |
| jam | and then we see how much more we can fit | 13:00 |
| lifeless | good | 13:01 |
| lifeless | that was with bzr.dev, with a chk index | 13:01 |
| ^_- | hmm | 13:07 |
| ^_- | i just upgraded to 1.6, and i'm having this problem with loggerhead (i'm a python coder, but still somewhat new to bzr): | 13:07 |
| ^_- | self._revision_graph = branch.repository.get_revision_graph(self._last_revid) | 13:07 |
| ^_- | AttributeError: 'KnitPackRepository' object has no attribute 'get_revision_graph' | 13:07 |
| ^_- | was something removed/changed in 1.6 to cause this? :/ | 13:08 |
| ^_- | i would normally browse the source but i don't even know where to begin heh | 13:08 |
| thumper | ^_-: which version of loggerhead are you using? | 13:09 |
| ^_- | thumper, latest from trunk | 13:10 |
| beuno | ^_-, are you sure? That has been fixed in trunk months ago | 13:10 |
| lifeless | whose trunk? | 13:10 |
| beuno | loggerhead's | 13:10 |
| beuno | is there anither one I'm not aware of? | 13:10 |
| lifeless | beuno: I was asking ^_- | 13:10 |
| ^_- | beuno, i believe so | 13:10 |
| lifeless | URL | 13:11 |
| beuno | lifeless, ah, good point :) | 13:11 |
| ^_- | http://www.lag.net/robey/code/loggerhead/ | 13:11 |
| ^_- | maybe i'm using the wrong trunk @_@ | 13:11 |
| beuno | ^_-, https://code.edge.launchpad.net/loggerhead | 13:11 |
| lifeless | exactly as I thought | 13:12 |
| lifeless | :P | 13:12 |
| beuno | lifeless, you have a real nack to identify those things | 13:12 |
| beuno | ^_-, https://code.edge.launchpad.net/~loggerhead-team/loggerhead/trunk to be more exact | 13:12 |
| ^_- | ah, thanks ^_^ | 13:12 |
| beuno | we also have a full release | 13:12 |
| beuno | if you prefer tarballs | 13:12 |
| lifeless | beuno: assume anything that can go wrong, has | 13:12 |
| beuno | lifeless, I have a lot to learn :) | 13:14 |
| lifeless | soon the student shall exceed the teacher | 13:17 |
| pasky | sounds very epic | 13:19 |
| pasky | will there be lightsaber battels? | 13:19 |
| ^_- | ergh | 13:34 |
| === gour|lunch is now known as gour | ||
| zartosss | hi all | 13:36 |
| zartosss | i have a noob question ( ;) ) | 13:37 |
| zartosss | i follow a project on launchpad, i create a repository with bzr init-repo myproject | 13:38 |
| zartosss | i go to /myproject | 13:38 |
| zartosss | i use bzr branch lp:myproject | 13:38 |
| zartosss | it's download sources | 13:39 |
| zartosss | but i can't use bzr diff or bzr status ... | 13:39 |
| zartosss | it's write 'not a branch' for diff and 'no WorkingTree exists ...' for status | 13:40 |
| zartosss | smb can help me? | 13:40 |
| james_w | zartosss: "cd myproject" again | 13:40 |
| james_w | so that you are inside the branch you just got, not the shared repository you created first | 13:40 |
| zartosss | i try this two command in and outside the repository (with add myproject when i am outside)... | 13:42 |
| zartosss | but its the same | 13:42 |
| bob2 | the repository isn't the problem | 13:42 |
| bob2 | none of the comands will do anything unless you are in the /branch/ | 13:42 |
| bob2 | which is myproject/myproject, in your case | 13:43 |
| gnomefreak | have we upgraded bzr to 1.2? | 13:44 |
| zartosss | i use bzr 1.5 i think | 13:44 |
| gnomefreak | sorry i meant server | 13:44 |
| gnomefreak | zartosss: me too but im still getting warning sort of | 13:45 |
| gnomefreak | Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) | 13:45 |
| zartosss | it's launchpad, i suppose they are more geek than me :P | 13:45 |
| gnomefreak | ok this branch is small and its taking forever to pull i would think its unrelated to the above | 13:46 |
| zartosss | ok bob | 13:47 |
| zartosss | its good | 13:47 |
| zartosss | i just start my brain ;) | 13:47 |
| zartosss | thx for the help | 13:47 |
| muffinresearch | Hi, does anyone know the current status of nested tree support. Does it work reliably? I found this reference which suggests that it's still experimental but it's not all that up to date: https://lists.ubuntu.com/archives/bazaar/2007q2/026807.html | 13:49 |
| zartosss | if there is no diff between my local repository and lauchnpad , bazaar doesn't write smg ? it's normal ? | 13:49 |
| lifeless | gnomefreak: high, check in ~/.bzr.log for irregularities | 13:50 |
| lifeless | muffinresearch: its not up todate, LarstiQ has more details | 13:50 |
| lifeless | zartosss: what do you mean? | 13:50 |
| ^_- | hrm i keep getting this error with loggerhead: bzrlib.errors.NotBranchError: Not a branch: "/usr/home/bzr/bzr-repos/libost/.bzr/branch/". | 13:53 |
| zartosss | i use bzr diff, and after bzr juste rewrite the repository where i am | 13:53 |
| ^_- | here's the relevant portion of my loggerhead.conf file: http://pastebin.ca/1185262 | 13:53 |
| zartosss | C:\Program Files\Bazaar>bzr diff gephibzr/gephi | 13:54 |
| zartosss | C:\Program Files\Bazaar> | 13:54 |
| zartosss | its juste write that | 13:55 |
| zartosss | its want to mean there is no diff ? | 13:55 |
| lifeless | ^_-: is libost a repository? | 13:55 |
| lifeless | ^_-: or a branch? | 13:56 |
| lifeless | zartosss: tat means there is no diff yes, you can also use 'bzr st' which can tell you more info | 13:56 |
| ^_- | lifeless, libost is a repository yes | 13:56 |
| lifeless | ^_-: so, there is no branch there, only under it ? :) | 13:57 |
| ^_- | lifeless, there is trunk | 13:57 |
| ^_- | under it | 13:57 |
| gnomefreak | lifeless: i cant see anything wrong but i also cant compare it to anything since most of that file is trace backs http://pastebin.mozilla.org/525889 | 13:57 |
| lifeless | gnomefreak: are you using http or bzr+ssh? http logs some stuff, can detect network packet loss | 13:58 |
| lifeless | we've had some weird network interactions recently | 13:58 |
| gnomefreak | im using bzr lp: hold on ill get you exact commands | 13:59 |
| lifeless | ^_-: right, but you are telling loggerhead that libost itself is a branch, which its not | 13:59 |
| gnomefreak | bzr branch lp:~gnomefreak/firefox-extensions/firegpg.upstream | 13:59 |
| lifeless | ^_-: put the actual branch path there | 13:59 |
| ^_- | lifeless, ah i see | 14:00 |
| lifeless | ^_-: for that simple a config though, just use serve-branches, its much easier | 14:00 |
| lifeless | e.g. server-branches /usr/home/bzr/bzr-repos/libost | 14:01 |
| ^_- | lifeless, what does server-branches do? | 14:02 |
| lifeless | serve-branches sorry, it serves out branches | 14:03 |
| zartosss | bye all thx for speed help ! | 14:03 |
| ^_- | lifeless, is there an example anywhere? :) | 14:03 |
| lifeless | ^_-: I just gave you the example | 14:03 |
| lifeless | ^_-: serve-branches /usr/home/bzr/bzr-repos/libost | 14:04 |
| ^_- | lifeless, i mean in the conf file | 14:04 |
| ^_- | wait nvm | 14:04 |
| lifeless | no conf file | 14:04 |
| ^_- | i'm stupid | 14:04 |
| ^_- | lifeless, but i'm serving multipule branches | 14:04 |
| ^_- | actually multipule repos | 14:05 |
| ^_- | that was the one that was causing an error though | 14:05 |
| lifeless | are they all in a single root folder? | 14:05 |
| lifeless | ^_-: if so, perhaps serve-branches /usr/home/bzr/bzr-repos | 14:05 |
| lifeless | is all you need | 14:05 |
| ^_- | File "/usr/local/bin/serve-branches", line 28, in <module> | 14:06 |
| ^_- | from loggerhead import __version__ | 14:06 |
| ^_- | ImportError: cannot import name __version__ | 14:06 |
| lifeless | is loggerhead in your normal python path? | 14:06 |
| lifeless | if its not, make sure you export PYTHON_PATH appropriately | 14:07 |
| * ^_- facepalms | 14:08 | |
| ^_- | hm i got it to work | 14:09 |
| ^_- | thanks lifeless :D | 14:09 |
| lifeless | ^_-: no probs | 14:19 |
| lifeless | ^_-: hope you like the new version :) | 14:19 |
| pygi | ^_-, what a nick xD | 14:20 |
| === mw|out is now known as mw | ||
| Leonidas | hmm, I have trouble finding some revision in the bzr source | 14:39 |
| jam | ugh, lifeless you still around? | 14:39 |
| lifeless | jam: yes | 14:40 |
| Leonidas | bzr log -r revid:john@arbash-meinel.com-20050709180338-33e3b5a778df9104 | 14:40 |
| Leonidas | can someone tell me, where it is? There had to be such a revision. | 14:41 |
| james_w | Leonidas: where did you get the revid from? | 14:41 |
| james_w | I think that revision is a ghost | 14:41 |
| Leonidas | james_w: I was walking the tree via hg convert (I'm trying to create a bzr plugin for it) and it somehow found that revision. | 14:42 |
| Leonidas | james_w: so the bzr source contains revid that do not exist (anymore) | 14:43 |
| Leonidas | ? | 14:43 |
| james_w | Leonidas: yeah I imagine it is one of the ghost's in bzr's history | 14:43 |
| Leonidas | james_w: how do such ghosts happen (so that I can reproduce such a repository using a unittest)? | 14:44 |
| lifeless | Leonidas: bzr's history cannot be fully represented by hg | 14:44 |
| LarstiQ | Leonidas: you can grep for ghost in bzrlib/tests/ | 14:44 |
| Leonidas | lifeless: every conversion looses some information (like directories, which hg does not track at all), but I'm trying to get it to convert as accurately as possible | 14:45 |
| lifeless | Leonidas: bzr ghosts - references to history not present locally - require a hash to be included in hg repositories, and the hash is representation specific -> it can't be synthesised without the history, and thats whats missing in the first place :) | 14:46 |
| * Leonidas is reading http://bazaar-vcs.org/GhostRevision - nice, it has some docs :) | 14:47 | |
| lifeless | as to how they can be created, just do a commit with an absent parent | 14:47 |
| chombee | Hey, does bzr have an equivalent to GitHub? | 14:47 |
| Leonidas | lifeless: is there a way to do this using the ``bzr`` command or do I have to use bzrlib? | 14:47 |
| lifeless | chombee: sure, launchpad, or savannah, or alioth | 14:47 |
| lifeless | Leonidas: bzrlib | 14:48 |
| Leonidas | oh, ok. | 14:48 |
| Leonidas | speaking about launchpad, does it support stacked branches already? | 14:48 |
| lifeless | kindof, there are some glitches | 14:49 |
| lifeless | look for an announcement soon | 14:49 |
| lifeless | jam: so, did you and vila *both* totally miss the point of my email about ContainerWriter ? | 14:50 |
| jam | lifeless: your summary message was a bit... terse | 14:50 |
| Leonidas | lifeless: uhm, so how does bzr handle such ghosts? As far as I saw, it is pretenting that there is no such revision at all. | 14:51 |
| lifeless | Leonidas: often yes | 14:51 |
| lifeless | Leonidas: but we keep the pointer and can join up later | 14:51 |
| lifeless | jam: so, the writer add method requires a buffer; this causes high memory use | 14:52 |
| vila | lifeless: I think we both missed the context and just jumped the gun on seek(0, 2) :-) | 14:52 |
| lifeless | vila: context is all there | 14:52 |
| jam | Yeah, you already use .tell() here and there, I'm a bit surprised you need seek | 14:52 |
| jam | I don't really see what prevents you from writing it spooled | 14:52 |
| jam | And if packs are defined as length-prefixed, I don't see how you can get away with not needing to know the size of a page before it is written | 14:53 |
| lifeless | bzrlib.pack.ContainerWriter | 14:53 |
| lifeless | is length prefixed records | 14:53 |
| Leonidas | lifeless: hmm, thats cool, so if I somehow join two repos I could get the parents of the revision, right? | 14:53 |
| lifeless | you can seek cheaply on a finished BTreeGraphIndex, because there is a local tempfile | 14:53 |
| lifeless | Leonidas: yes | 14:54 |
| lifeless | Leonidas: but it also handles deliberate expunging much the same | 14:54 |
| lifeless | (where there is no ability to join cause its really gone :)) | 14:54 |
| lifeless | jam: I don't know why you are talking about pages | 14:54 |
| Leonidas | Is there some way to find the revision which references my ghost revision as parent? I'd like to take a look at the parent revision in IPython and play with it a bit. | 14:54 |
| vila | lifeless: sry, I meant I misunderstood *indices* as referring to big blobs instead of indices *being* the big blobs | 14:55 |
| lifeless | vila: right, that explains some of the confusion | 14:55 |
| jam | lifeless: I'm calling a page a "length-prefixed bytes" | 14:55 |
| jam | I'll try not to use confusing terms | 14:55 |
| lifeless | jam: please, as I don't consider 300MB a 'page' | 14:55 |
| jam | lifeless: so... how would you write out a length-prefixed page if you don't know the length, are you proposing to get rid of length-prefixed entries? | 14:56 |
| jam | Or at least, make it optional? | 14:56 |
| lifeless | jam: I'm proposing an additional method that takes a file object which supports seek(0,2); tell() | 14:56 |
| lifeless | jam: which thus supports knowing the length | 14:57 |
| lifeless | jam: these things are called records | 14:57 |
| lifeless | thats the official termin the code, please don't call them apges | 14:57 |
| jam | lifeless: ok, so the confusing part for *me*. You aren't changing Writer to support seek(0, 2) .tell() | 14:57 |
| jam | but that you are *passing in* | 14:57 |
| jam | an object that can do thta | 14:57 |
| jam | that | 14:57 |
| lifeless | right | 14:57 |
| vila | lifeless, jam: some confusion for me | 14:57 |
| lifeless | I'm requiring the parameter to the new method to support these two methods | 14:58 |
| jam | vila: s/some/same/ ? | 14:58 |
| vila | jam: yes, *same* :-/ | 14:58 |
| jam | lifeless: right, I think the statement "I'm thinking of requiring a file object" sounded more like *underneath* CW | 14:58 |
| jam | not *above* | 14:58 |
| jam | So are you thinking to spool to a local file then? | 14:58 |
| lifeless | it wouldn't make sense to do it under CW, it would be inefficient | 14:58 |
| lifeless | jam: if you want to use this method, yes | 14:58 |
| jam | I'm just curious how you would support seek(0, 2).tell() without buffering | 14:58 |
| jam | lifeless: I'm saying that we both read what you wrote | 14:59 |
| jam | and thought you were talking about underneath | 14:59 |
| jam | not above | 14:59 |
| lifeless | jam: I'm not proposing to change code that uses the current interface, like I said, I'm proposing that I add an interface | 14:59 |
| jam | which is why we were confused | 14:59 |
| jam | So... your proposal seems fine to me | 14:59 |
| jam | now that I actually understand it | 14:59 |
| lifeless | :P | 14:59 |
| jam | lifeless: so you know, if you would review my proposed changes, you could get a Btree index that will probably not fault for your bzr-search indices ... :) | 15:04 |
| jam | ;) | 15:04 |
| lifeless | jam: its high on my list | 15:04 |
| lifeless | I've been merging path_info | 15:04 |
| lifeless | its thousands of conflicts | 15:04 |
| lifeless | :( | 15:04 |
| jam | "path_info" is that the tokens stuff? | 15:04 |
| lifeless | yeah | 15:05 |
| lifeless | C stat-and-process in one hit | 15:05 |
| lifeless | sorry, no, not 'path tokens' | 15:05 |
| lifeless | fast-stat | 15:05 |
| lifeless | no objects etc | 15:05 |
| jam | Ah, ok. I remember that being around a while ago. I'm surprised it has so many conflicts | 15:05 |
| jam | It seemed rather self-contained | 15:05 |
| jam | I wonder if it is a bad merge base | 15:05 |
| jam | you might try --weave :) | 15:05 |
| lifeless | well, midnight, time for beauty sleep | 15:07 |
| BasicPRO | hmm | 15:07 |
| jam | lifeless: be pretty :) | 15:07 |
| BasicPRO | never try to do serious work from a coffee house hotspot! | 15:08 |
| === BasicPRO is now known as BasicOSX | ||
| jaypipes | Hello Bzr gurus! I'm having reports of performance issues when branching the lp:mysql-server repo from bzr clients 1.6 and below. 1.3 is apparently taking hours to complete whilst 1.6 is taking approximately 80 minutes. Does anyone know of any known performance issues with either the Launchpad bzr server or slowdowns for *very large* repos like the mysql server one? Thanks in advance! | 15:10 |
| ^_- | 09:19 < lifeless> ^_-: no probs | 15:11 |
| ^_- | 09:19 < lifeless> ^_-: hope you like the new version :) | 15:11 |
| ^_- | i do :D | 15:11 |
| ^_- | 09:20 < pygi> ^_-, what a nick xD | 15:11 |
| ^_- | hah | 15:11 |
| ^_- | :P | 15:11 |
| gnomefreak | sorry lifeless i had to get up due to phone, what did you mean by the following: | 15:12 |
| gnomefreak | 08:59 < gnomefreak > bzr branch lp:~gnomefreak/firefox-extensions/firegpg.upstream | 15:12 |
| gnomefreak | 08:59 < lifeless > ^_-: put the actual branch path there | 15:13 |
| james_w | gnomefreak: I don't think that comment was directed at you | 15:14 |
| gnomefreak | james_w: ah thanks | 15:15 |
| Leonidas | how do I get changes from a ghost revision? | 15:27 |
| Leonidas | I mean, I have the revision now, which has two parents: | 15:27 |
| Leonidas | one is an actual revision and the other is a ghost revision. What to do? Just ignore the latter? | 15:28 |
| james_w | Leonidas: yeah, I think that's all you can do for the conversion | 15:31 |
| Leonidas | james_w: so, there are no changes from the ghost? | 15:32 |
| james_w | well, there presumably are, but you can't know what they are without the revision | 15:33 |
| Leonidas | uh. An add via ghost and a rename of the added file in a non-ghost revision would break the conversion totally. | 15:35 |
| james_w | how so? | 15:36 |
| james_w | you would just assume that the file was added in the child of the ghost | 15:36 |
| james_w | just treat ghost parents as though they don't exist | 15:37 |
| Leonidas | james_w: because the source file that was contributed by the ghost would not be included into the converted repository | 15:37 |
| Leonidas | ok, I'll do that. Is there any better way for checking for ghosts than doing get_revision(id)? | 15:38 |
| james_w | well, it obviously breaks if it's not included, but it can be included | 15:38 |
| Leonidas | http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.dirstate.DirState.html#get_ghosts | 15:38 |
| james_w | graph.get_parent_map() does something with ghosts | 15:38 |
| james_w | I can't remember right now, but that allows you to detect ghosts without having to extract revisions | 15:39 |
| james_w | you are presumably extracting revisions anyway, so it may not be a big win | 15:39 |
| Leonidas | james_w: thanks, I'll look into it. | 15:39 |
| jam | jaypipes: I wouldn't be surprised to see pre 1.6 clients a bit slower with launchpad's 1.6 process. I *would* be surprised if bzr-1.6 clients were also slower. | 15:45 |
| jam | I don't know of any specifics | 15:45 |
| Leonidas | james_w: {'mbp@sourcefrog.net-20050711064100-c2eb947e0212f487': ('mbp@sourcefrog.net-20050711063455-0f0b87a770873373', 'john@arbash-meinel.com-20050709180338-33e3b5a778df9104')} | 15:45 |
| jam | But I know we got rid of a smart request that clients 1.2-1.5 were using | 15:45 |
| james_w | Leonidas: that's get_parent_map output? | 15:45 |
| jam | it didn't scale particularly well, and we have a better method in 1.6 | 15:45 |
| Leonidas | james_w: this is what get_parent_map() returns | 15:45 |
| jam | and clients 1.2-1.5 fall back to a pre 1.2 form. | 15:46 |
| Leonidas | james_w: repo.get_parents_map() | 15:46 |
| james_w | Leonidas: call it on the john@arbash-meinel.com-20050709180338-33e3b5a778df9104 one | 15:46 |
| james_w | Leonidas: you'll get {} I believe | 15:46 |
| Leonidas | james_w: yeah, you're right - thanks. | 15:46 |
| james_w | Leonidas: "revid not in map.get_parent_map([revid])" indicates a ghost | 15:47 |
| Leonidas | james_w: I am extracting revisions, but hg commit uses two phases: first it gathers all revisions and then it extracts them. So I'd either need to extract it twice otherwise or to cache them. But then memory rises and converting 40k revisions would propably use up quite a lot of memory. | 15:48 |
| jaypipes | jam: yeah, that's true. However, I am seeing reports of 1.6 clients taking 80+ minutes to branch from lp:mysql-server. Myself, it only takes about 20-30 minutes on a good connection, but wondering if you'd heard anything of that nature? | 15:51 |
| jam | jaypipes: Why aren't these people using shared repos... it would go down to like 1-2 minutes anyway | 15:52 |
| jam | I haven't heard of any specific regressions like that, no. | 15:52 |
| jam | well, until now :) | 15:52 |
| jaypipes | jam: this is definitely using a shared repo (I assume you mean init'ing with bzr init-repo?). | 15:52 |
| jam | jaypipes: so.. why isn't there any data pre-seeded in the repository? | 15:53 |
| jam | Certainly if it took even 20minutes with a pre-seeded repository, I would be surprised | 15:53 |
| jam | jaypipes: If you can reproduce it at all, you might try a "bzr -Dhpss" run to see if there is something obvious going on. | 15:54 |
| jam | Though that is going to be a large log file | 15:54 |
| jam | I'll be back in a few minutes | 15:54 |
| jaypipes | jam: ok, thx for the pointer. | 15:54 |
| Leonidas | james_w: the conversion fails pretty quickly, because it encounters files from ghost revisions which it has never seen before. | 16:06 |
| Leonidas | maybe I can capture the changes in some other way... | 16:06 |
| james_w | Leonidas: it sounds like your conversion is structured in an odd way | 16:06 |
| james_w | both the ways I can think of to do it wouldn't hit this problem. | 16:07 |
| Leonidas | the problem looks like this, I had this 4 days ago already where I was overlooking some revisions: | 16:09 |
| Leonidas | http://paste.pocoo.org/show/82984/ | 16:09 |
| Leonidas | <pmezard> Leonidas: the error is it cannot find the copy source file in either changeset parent | 16:10 |
| === thumper_laptop is now known as thumper | ||
| jam | Leonidas: so you are converting *from* bzr *to* hg? | 17:06 |
| jam | And, I presume, trying to do it so you can round trip? | 17:06 |
| Leonidas | jam: yeah, bzr->hg currently. Most things work, just the bazaar repo is currently not working. | 17:07 |
| jam | Leonidas: well, probably most repos don't have ghosts | 17:08 |
| jam | one issue is that hg and git cannot handle ghosts | 17:08 |
| jam | their revision ids are chained sha hashes | 17:08 |
| jam | so they don't have a way to represent a ghost | 17:08 |
| jam | Well, I suppose they could know about the sha value | 17:08 |
| jam | and just not have it stored | 17:08 |
| jam | but regardless, I'm pretty sure that isn't supported | 17:09 |
| jam | so you have to figure out how you want to represent it | 17:09 |
| Leonidas | no, it isn't. | 17:09 |
| jam | One possibility is to just ignore parents that are ghosts | 17:09 |
| jam | just pretend they never existed | 17:09 |
| Leonidas | thats what I'm doing now | 17:09 |
| jam | That would cause some issues with round-tripping | 17:09 |
| jam | but if you have to keep an alias map anyway | 17:09 |
| jam | (this revision id maps to this sha1 hash) | 17:09 |
| jam | you might be able to also keep a list of ghosts, and track what revisions pointed to them. | 17:10 |
| jam | Leonidas: if you have to grab the whole ancestry in order to convert, you may want to look at | 17:11 |
| jam | Graph.iter_ancestry() | 17:11 |
| jam | It has a slightly different api, in that it returns ('revision_id': None) for ghosts | 17:11 |
| jam | rather than silently omitting them | 17:11 |
| jam | But it would be a way to collect all the revision ids for the ancestry, and determine ghosts in one pass | 17:12 |
| jam | and then you could start using "get_revision(revision_id)" to actually extract the revision texts | 17:12 |
| Leonidas | jam: is there anything else besides ghosts that could make problems? | 17:17 |
| Leonidas | (ok, directories) | 17:18 |
| jam | Leonidas: we track directories and they don't | 17:18 |
| Leonidas | jam: i'm already filtering out directory changes | 17:18 |
| markvandenborre | I'm developing a simple web app (using the django framework), and I wonder about the best way to put that into version control | 17:21 |
| markvandenborre | it's mostly a very simple thing | 17:21 |
| jam | Leonidas: also we represent renaming a directory as just that "mv dir/ dir2/" | 17:21 |
| jam | Leonidas: I believe hg represents it as a contents move | 17:22 |
| jam | so mv dir1 dir2 => mv dir1/* dir2/* | 17:22 |
| markvandenborre | but I wonder what I should do about server specific configuration information | 17:22 |
| jam | so there is a bit of translation you have to do | 17:22 |
| Leonidas | markvandenborre: heh. I'm doing the same :) | 17:22 |
| jam | Again, if you are planning a 1-way conversion, it is a lot cheaper than if you plan on round-tripping the data | 17:22 |
| jam | markvandenborre: So the common way to do it | 17:22 |
| jam | is to have a "foo.conf.template" file | 17:22 |
| jam | and version *that* | 17:22 |
| Leonidas | jam: It probably is a file move. | 17:23 |
| jam | and then individual people copy that to "foo.conf" and modify it | 17:23 |
| markvandenborre | jam, thx for that suggestion | 17:23 |
| jam | Leonidas: I just wanted to point out that you have to translate it. And if you wanted to *round-trip* the information, then you need a way to detect it on the way back | 17:23 |
| jam | Especially given that you can rename a directory with no contents... | 17:23 |
| jam | But if you just want to get the data out | 17:23 |
| jam | I'm curious why "bzr fast-export | hg fast-import" is not sufficient | 17:24 |
| Leonidas | jam: But I am not sure whether I am really going for roundtrip functionality, because somehow I would never get the same repo out as the one I started with. | 17:24 |
| Leonidas | jam: no hg fast-import. | 17:24 |
| Pilky | is there any particular reason why the "Branched x revision(s)" text at the end of a 'bzr branch' operation is sent as an error and not output? | 17:24 |
| Pilky | *not regular output | 17:25 |
| Leonidas | jam: at least nothing integrated. There is hg-fast-export by the git folks and hg-fast-import by someone else. | 17:25 |
| Leonidas | jam: after I get the convert bzr to run fine, I might thing about fastim-/export. Maybe it can be plugged into the ConvertExtension, which would be quite elegant. | 17:26 |
| Leonidas | (but probably everything but fast) | 17:26 |
| jam | Leonidas: I think the big win is having a common stream format | 17:27 |
| jam | which allows everyone to play together | 17:27 |
| jam | even if it can be a bit lossy | 17:27 |
| Leonidas | jam: I agree. This is why I'd like to plug it in into ConvertExtension, which is the common conversion API in mercurial. | 17:29 |
| === maw_ is now known as mw | ||
| CardinalFang | Hi all. | 18:13 |
| CardinalFang | On the machine that holds our "trunk" branches, I have some automated voodoo that scans the trees occasionally and updates our bug database. | 18:13 |
| CardinalFang | My problem is that new work on the trunk, where the developer has to run "bzr merge", changes the order of the revisions, and I can't easily tell what is new. | 18:16 |
| luks | are you using bzrlib directly for this? | 18:19 |
| CardinalFang | Do I have to keep state? seen_revision_ids = load_from_history() | 18:19 |
| CardinalFang | luks, No, I'm not. | 18:19 |
| CardinalFang | luks, Though, I'm not above that. | 18:20 |
| luks | hmm, I'm not sure how to do that using the command line | 18:20 |
| james_w | CardinalFang: you store the revision id of the tip last time you scanned? | 18:20 |
| CardinalFang | james_w, yes, I have that. | 18:20 |
| luks | using bzrlib you have basically two options: use the post tip change hook (if you are using a smart server), remeber the revision id you last scanned and then check the difference in ancestries | 18:21 |
| james_w | CardinalFang: and what info do you want? is log sufficient? | 18:21 |
| james_w | does "bzr log -r last_revid.." do what you want? | 18:21 |
| james_w | ah, but that will give you last_revid again | 18:22 |
| luks | I wouldn't expect ranges to work "correctly" on non-mainlien revisions | 18:22 |
| CardinalFang | james_w, I get too much. A dev branches trunk, works for a while, commits. Tries to push, then merges from trunk, commits, pushes. The "log" output has everything between branch and merge-commit as part of his change history. | 18:24 |
| james_w | CardinalFang: I'm not how to do it from the UI | 18:24 |
| Discerer | hey! is there a trac-like alternative for bzr? | 18:26 |
| Discerer | except launchpad | 18:26 |
| luks | there isn't, as far as I know | 18:26 |
| luks | but there is a bzr plugin for trac | 18:26 |
| sohail | anyone know the cause of this: C:\ssci-code>bzr pull -v | 18:27 |
| sohail | Using saved location: sftp://sohail@10.0.2.101/home/sohail/bzr/code/master/ | 18:27 |
| sohail | bzr: ERROR: Unable to connect to SSH host 10.0.2.101; EOF during negotiation | 18:27 |
| james_w | sohail: "ssh 10.0.2.101 true" | 18:28 |
| james_w | oh, windows, sorry | 18:28 |
| sohail | james_w, huh? | 18:28 |
| luks | and also sftp, not ssh | 18:28 |
| sohail | yes windows... | 18:28 |
| james_w | I'm not sure how to debug that. | 18:28 |
| luks | bzr version should give you a location of a log file, anything interesting in thate? | 18:28 |
| james_w | sohail: can you see if there is anything relevant at the end of ~/.bzr.log | 18:29 |
| sohail | james_w, luks http://rafb.net/p/Az9DVs62.html | 18:31 |
| luks | plink might be the problem | 18:31 |
| luks | try `set BZR_SSH=paramiko` | 18:31 |
| luks | and then run bzr pull | 18:31 |
| luks | at least I know sftp uses this variable too | 18:31 |
| luks | er, s/I know/I think/ | 18:32 |
| sohail | ok let me try | 18:32 |
| sohail | luks, http://rafb.net/p/xkyUoi65.html :-) | 18:35 |
| luks | parimoko | 18:35 |
| luks | it should be paramiko | 18:35 |
| sohail | oops | 18:35 |
| luks | but I wonder what are the " I'm still here waiting for something to do..." lines :) | 18:35 |
| sohail | luks, probably tortoisebzr | 18:36 |
| sohail | that worked! | 18:36 |
| luks | oh | 18:36 |
| sohail | so I guess I should set the environment variable | 18:36 |
| luks | I thought it was supposed to use paramiko by default | 18:36 |
| sohail | I vaguely remember futzing around with BZR_SSH before | 18:36 |
| luks | I'm not sure why it doesn't | 18:36 |
| luks | there were some problems with using plink | 18:36 |
| sohail | well atleast there is a workaround! thanks for your help :-) | 18:38 |
| luks | no problem | 18:38 |
| james_w | was it someone here who wrote setuptools_bzr? | 18:51 |
| luks | barry warsaw wrote that, no? | 18:53 |
| james_w | ah yes, apparently | 18:54 |
| Leonidas | james_w: I still have issues with the ghost revisions which introduce unknown changes. Take the example of revision 2 which has two parents: rev 1 and a ghost revision | 18:56 |
| Leonidas | ghost revision adds a file; revision 3 renames this file. | 18:56 |
| Leonidas | so how to get the file? | 18:57 |
| luks | it will probably appear in r3 as added | 18:57 |
| james_w | Leonidas: you should consider it added in r2 | 18:59 |
| james_w | how do you detect when files are added? | 19:00 |
| luks | oh, right, r2 | 19:00 |
| james_w | if you import revisions as snapshots then it should guess that it was added in r2 | 19:00 |
| luks | I misread the original sentence | 19:00 |
| Leonidas | james_w: I am doing iter_changes between the revision and its parents. | 19:00 |
| james_w | if you import then as diffs then you provide a diff from r1 to r2, which will show the file as added, even though it was really added in the ghosts | 19:01 |
| Leonidas | james_w: so when I ignore the parent that is a ghost, I'm not doing that particular iter_changes that includes the rename | 19:01 |
| james_w | Leonidas: I don't see how you are missing the rename by ignoring the parent | 19:05 |
| james_w | doesn't iter_changes(r1, r2) show the file being added? | 19:05 |
| Leonidas | james_w: I'm not sure. I have to construct such a repo with ghosts first, because bzr.dev is too big to be used for testing. | 19:06 |
| james_w | Leonidas: just tree.add_parent_id('ghost') | 19:07 |
| james_w | tree.commit("message") | 19:07 |
| james_w | I think | 19:07 |
| james_w | after an inital commit I think | 19:07 |
| Leonidas | james_w: but I need to add the file in the ghost revision... | 19:12 |
| james_w | Leonidas: ah, true | 19:13 |
| james_w | though bzr is snapshot based, so I don't see what difference that makes | 19:13 |
| abentley | jelmer: ping | 19:14 |
| jelmer | abentley, hi | 19:14 |
| abentley | Hi jelmer. How bad would it be if BzrDir.sprout didn't use Branch.sprout? | 19:15 |
| jelmer | abentley, it would mean I would have to overload BzrDir.sprout, probably :-) | 19:16 |
| jelmer | abentley, other than that, shouldn't be a big deal (for bzr-svn, at least) | 19:16 |
| abentley | This is a problem related to stacking. | 19:16 |
| jelmer | what are you trying to use instead? | 19:17 |
| abentley | We want to be able to branch from a format that doesn't support stacking into a format that does. | 19:17 |
| Leonidas | james_w: the problem is that I am missing some changes and I suspect this is due the fact that I ignore all changes that come from ghosts. I'm currently reading the tests on how to create such a small repo for testing. | 19:17 |
| abentley | But Branch.sprout will use the source branch's format. | 19:17 |
| abentley | jelmer: I am using Repository.fetch, BzrDir.create_branch, Branch.copy_content_into, Branch.set_parent_info. | 19:19 |
| jelmer | abentley: In my case, I'm using a different format | 19:19 |
| abentley | I guess that's actually BzrDirFormat.create_branch | 19:19 |
| jelmer | abentley, But still using sprout | 19:19 |
| jelmer | abentley, cloning_metadir() returns 'rich-root-pack' for svn BzrDirs | 19:20 |
| abentley | Cool, and we'll respect that unless user passes --stacked, and we have to upgrade the format. | 19:21 |
| abentley | jelmer: So is SvnBranch.sprout creating a BzrBranch6? | 19:22 |
| jelmer | abentley: it's calling self.bzrdir.create_branch() | 19:22 |
| jelmer | (so doesn't bother with formats at all) | 19:23 |
| abentley | jelmer: I would expect that to create a subversion branch. | 19:23 |
| jelmer | abentley, you can't create a standalone subversion branch | 19:23 |
| jelmer | not in a .bzr/ parent dir, at lesat | 19:23 |
| abentley | jelmer: sure. So why doesn't that raise an exception? | 19:24 |
| jelmer | abentley: sorry, my bad | 19:24 |
| jelmer | abentley, it calls target.create_branch() | 19:24 |
| jelmer | not self.bzrdir.create_branch() | 19:25 |
| jelmer | and target will be whatever it's copying into, usually a rich-root-pack bzrdir | 19:25 |
| abentley | jelmer: That's basically what I want BzrDir.sprout to do, but the Bazaar implementation uses the source metadir format, not the target. | 19:25 |
| abentley | jelmer: So maybe we should just break compatibility and require Branch.sprout to take a format parameter? | 19:27 |
| jelmer | abentley: Sounds sensible to me | 19:27 |
| Leonidas | james_w: is it possible that a ghost does introduce any changes? I took a look at test_revision.py, make_branches() and the B tree does not seem to get any actual changes from the A tree, just a seemingly random parent_id. | 19:41 |
| james_w | Leonidas: well, there is no point in specifying any changes, as there is nowhere to store them | 19:43 |
| abentley | Leonidas: It's possible for any revision does not introduce any changes. This includes ghosts. | 19:43 |
| james_w | Leonidas: and as it's snapshot based you can just consider any changes to be included by the child in your case | 19:43 |
| Leonidas | james_w: sounds logical. Maybe the problem is somewhere else. | 19:44 |
| hsn_ | what are stacked branches? | 19:48 |
| === mw is now known as mw|food | ||
| jam | jelmer: since you have a 0.4.11 release, do you need me to package it? | 19:59 |
| jelmer | jam, it's probably worth waiting for the final release (only released rc2) | 19:59 |
| jam | oh, I guess it is 0.4.11rc2 | 20:00 |
| jam | I'll give it a shot anyway | 20:00 |
| jelmer | there was a typo in the announcement saying it was 0.4.12 | 20:00 |
| jelmer | sending out release announcments at 5 AM is a bad idea, apparently | 20:00 |
| jam | a lot of things are a bad idea at 5 AM | 20:01 |
| jelmer | wasn't that the whole reason for dvcs in the first place? | 20:01 |
| jam | To not send release announcements at 5 am? | 20:02 |
| jam | :) | 20:02 |
| jelmer | (-: | 20:02 |
| jelmer | I meant being able to commit drunk without bothering anybody | 20:02 |
| jam | jelmer: I just merged lp:bzr-svn and I don't see a 0.4.11-rc2 tag | 20:03 |
| jelmer | looks like I forgot that as well at 5 AM.. | 20:03 |
| jelmer | please try again | 20:03 |
| jelmer | or use -r1667 | 20:04 |
| jelmer | not sure how lp mirrors these days | 20:04 |
| james_w | jelmer: what versions do you want in Intrepid? | 20:04 |
| jelmer | james_w, I assume the aim is to have 1.6 in intrepid? | 20:04 |
| jam | jelmer: if you pushed to bzr+ssh, I should get the same copy, I believe | 20:04 |
| jelmer | in that case, 0.4.11 | 20:04 |
| james_w | jelmer: bzr 1.6, bzr-gtk 0.95, latest of everything else | 20:04 |
| jelmer | james_w, yeah, 0.4.11 then | 20:05 |
| james_w | jelmer: cool, if you could get that in experimental tonight it would make things much easier. | 20:05 |
| jam | well, he'd have to actually *release* it :) | 20:06 |
| james_w | I can get all the sync requests filed tonight, and then find a bzr fan with upload rights to ack them all, and then should sneak in for FF. | 20:06 |
| jam | jelmer: "bzr tags --show-ids -d lp:bzr-svn" shows no 0.4.11~rc2 | 20:06 |
| james_w | ah, I misunderstood. | 20:06 |
| jam | He has 0.4.11~rc2 released | 20:07 |
| jam | so he's close | 20:07 |
| jam | And it *is* the one that matches bzr-1.6 | 20:07 |
| jelmer | james_w, I might not make 0.4.11 tonight, but rc2 should be fine as well (and is already in experimental) | 20:07 |
| jelmer | jam: I'm pushing to http://people.samba.org/bzr/jelmer/bzr-svn/0.4 | 20:07 |
| james_w | jelmer: cool, thanks, it's just sorting out -gtk then I think | 20:08 |
| james_w | we should also consider backporting fixes to 1.6 as they come up so we have something solid | 20:08 |
| jelmer | james_w, bzr-gtk should already be ok in experimental | 20:09 |
| james_w | yeah, but there was an ubuntu upload, I need to check we can overwrite it | 20:09 |
| jam | jelmer: did we get packages for bzr-gtk? | 20:10 |
| james_w | I think you had all the fixes upstream | 20:10 |
| jelmer | jam, in ppa, not anymore I think | 20:10 |
| jelmer | james_w, Yeah, I think I looked them up at one point | 20:10 |
| jam | jelmer: I'd like to get the basic plugins packaged into the ~bzr ppa if possible. I was told that you were the one who did bzr-gtk last time. | 20:11 |
| james_w | I would have stopped the upload, but it was his first contribution, so I let it go | 20:11 |
| jelmer | james_w, That's one of the things that could really improve, Ubuntu developers should send patches upstream (to Debian and further upstream)... | 20:11 |
| james_w | jelmer: yeah, I agree | 20:11 |
| jelmer | jam: I do most of the uploads of bzr-gtk for debian these days, it's been a while since I've uploaded it to ppa | 20:12 |
| jam | jelmer: it would be nice to have it done one way or another | 20:15 |
| jam | I seem to be taking up a bit more ppa activity lately if you need me to | 20:15 |
| jelmer | jam: I'm happy to help out now, but I'd rather not commit to keeping it up to date | 20:15 |
| jelmer | jam, Would updating it be a part of the bzr release process or is there somebody responsible? | 20:16 |
| jam | I don't know of anyone strictly responsible | 20:16 |
| jam | I'm considering doing it as part of the bzr packaging | 20:16 |
| jam | Though some of it still falls to the individual groups | 20:16 |
| jam | The big ones are bzr-svn, bzr-gtk, and bzrtools | 20:17 |
| jam | I'd like to at least get those packaged together | 20:17 |
| jelmer | yeah, I agree that'd be useful | 20:18 |
| jam | I keep using a bogus debian version for your code... :( | 20:19 |
| jam | First I used "bzr-svn-*" | 20:20 |
| jam | and then I forgot the "-1" | 20:20 |
| jam | I'm glad I wrote "bzr uncommit" | 20:20 |
| jelmer | btw, you may want to merge from the debian branch instead rather than the main bzr-svn branch - that should get you the packaging changes as well | 20:20 |
| jelmer | jam: :-) | 20:20 |
| jam | jelmer: where is the debian branch? | 20:20 |
| jam | (IMO, this is one of the reasons to have *separate* branches for code versus packaging, but I somewhat understand your ideas) | 20:21 |
| jelmer | http://bzr.debian.org/pkg-bazaar/$PACKAGE/unstable | 20:21 |
| jelmer | jam, I've uploaded bzr-gtk to the hardy ppa | 20:32 |
| jelmer | and lp:~bzr/bzr-gtk/ppa-hardy | 20:32 |
| jam | jelmer: your unstable package lists: +bzr-svn (0.4.11~rc1-3) experimental; urgency=low | 20:35 |
| jam | I'm a bit surprised it isn't ~rc2-1 | 20:35 |
| jelmer | Looks like I've forgotten to push it out to bzr.d.o yesterday night | 20:36 |
| jelmer | r312 | 20:36 |
| jam | lots of things missed at 5 am, I guess :0 | 20:36 |
| jelmer | Yeah, I'm surprised it didn't turn out to be a brown bag release (-: | 20:37 |
| jam | jelmer: so how do we get packages for feisty/gutsy/dapper for bzr-gtk? | 20:42 |
| jam | Are there packaging branches for it? | 20:42 |
| jelmer | not yet, I got distracted into fixing autoppa again :-) | 20:43 |
| jam | jelmer: so why is the branch "ppa-hardy/debian" when there is no source tree, (so it is like the packaging-hardy in bzr) | 20:49 |
| jelmer | jam: hysterical raisins | 20:50 |
| jelmer | or perhaps it's an evil plan by james to make sure all corner cases in builddeb get tested :-P | 20:51 |
| jam | so... I'm willing to clean things up and create the gutsy/intrepid packages | 20:51 |
| jam | But I'm not 100% sure what that entails | 20:51 |
| jam | the dependencies would all be the same, right? | 20:51 |
| === mw|food is now known as mw | ||
| jam | And how do you decide between "hardy-ppa" "ppa-hardy" and "packaging-hardy" ? | 20:52 |
| jam | (My personal pref is probably ppa-hardy so that the branches show up together in listings) | 20:52 |
| jelmer | jam: Yeah, the dependencies should be the same | 20:52 |
| jam | and ppa is shorter that "packaginG" | 20:53 |
| jelmer | jam: ppa-hardy seems like a better choice to me as well | 20:53 |
| === ^_- is now known as lol | ||
| jelmer | also makes it clearer to distinguish from the packaging branches used for debian and ubuntu | 20:53 |
| === lol is now known as ^_- | ||
| jam | I wonder what the deps change to for ~dapper1, I suppose I can peek at the ~dapper packages for bzr | 20:55 |
| Odd_Bloke | jam: Just caught up with email, good job on 1.6. :) | 20:57 |
| evarlast | anyone using sftp on win32? I installed pycrypto and paramiko, but it just hangs when I push. | 20:57 |
| jam | evarlast: do you have putty installed and on your path? | 21:00 |
| jam | You might try using | 21:00 |
| jam | set BZR_SSH=paramiko | 21:00 |
| jam | before running your command | 21:00 |
| jam | (otherwise it may detect plink and try to use it) | 21:01 |
| aidos | hello everyone | 21:05 |
| aidos | i was wondering, is there a smarter way to remove a remote branch than ssh -> rm -f myBranch/ ? | 21:05 |
| evarlast | jam: thank you. | 21:07 |
| aidos | about my branch question, no ideas? | 21:07 |
| jam | jelmer: Is there any reason to have these packages depend on "quilt" ? We don't use it at all | 21:08 |
| evarlast | jam: I think it was defaulting to paramiko, because I do have plink and cygwin ssh in my path, but initially it was not using those and was complaining about failing to import paramiko | 21:08 |
| jelmer | jam: When there are changes that are not upstream, we use quilt | 21:08 |
| jam | evarlast: You have to have paramiko for *sftp* support, but it is also an *ssh* provider | 21:09 |
| jam | jelmer: but... this is bzr-gtk and bzr | 21:09 |
| jam | When are there changes that are not upstream? | 21:09 |
| jelmer | jam: Yes, but the Debian packages have all carried patches that weren't upstream at some point | 21:09 |
| evarlast | plink would be ideal, since I do have putty ssh-agent running | 21:09 |
| jam | evarlast: paramiko can talk to pageant | 21:10 |
| jelmer | jam: Sometimes Debian-specific, sometimes important bugfixes that were cherrypicked | 21:10 |
| jam | And plink has some known issues handling user interaction | 21:10 |
| luks | I wonder why it's enabled by default again | 21:10 |
| luks | this is the second person today having a problem with it | 21:10 |
| jam | luks: we've talked about getting rid of that, just haven't gotten there | 21:11 |
| evarlast | "plink host ls " works perfectly and shows me a directory listing, so that is a great first step. | 21:11 |
| evarlast | will more -v's on my bzr push command give me more verbosity? | 21:12 |
| luks | well, it was disabled for some, and then enabled earlier this year | 21:12 |
| luks | *for some time | 21:12 |
| jam | luks: we added "-batch" because it at least doesn't hang prompting for a password, and people thought it was "safe" again. | 21:15 |
| luks | ah | 21:15 |
| jam | jelmer: any idea what the depends line would look like for bzr-gtk~dapper | 21:15 |
| jam | luks: now, it just fails right away | 21:16 |
| jam | which at least isn't hanging... | 21:16 |
| jelmer | jam, not sure - the same one as in hardy doesn't work? | 21:16 |
| jam | evarlast: generally no | 21:16 |
| jam | jelmer: python-central versus python-support I believe | 21:16 |
| jam | jelmer: I know it doesn't for bzr | 21:16 |
| jelmer | ah, right | 21:16 |
| jam | The history of bzr-gtk/ppa-hardy doesn't seem to include any time of python-support | 21:16 |
| jelmer | not of the top of my head, would be worth checking what's different between bzr/ppa-{dapper,hardy} | 21:17 |
| jelmer | yeah, bzr-gtk's package in Debian was created after the python policy changes | 21:17 |
| jam | yeah, I checked on that | 21:18 |
| jam | I'll do something | 21:18 |
| jam | and if someone complains, I'll fix it | 21:18 |
| jam | I don't have a dapper install anywhere | 21:19 |
| jam | and not really worth a virtual host | 21:19 |
| jelmer | yeah, same here | 21:20 |
| jam | well, ~dapper1, ~gutsy1, ~intrepid1 all uploaded for bzr-gtk | 21:21 |
| jam | We'll see if I've made mistakes | 21:21 |
| jam | Intriguing that nobody complains about no bzrtools other than ~hardy1 | 21:21 |
| Odd_Bloke | I guess it's because bzr and bzrtools are so often out of sync (IME) that people have started installing bzrtools in ~/.bazaar/plugins. | 21:25 |
| Odd_Bloke | Out of sync in terms of packaging, of course. | 21:25 |
| jam | jelmer: so is 'autoppa' meant to automate some of this stuff? | 21:26 |
| jam | (releasing a package for multiple platforms, etc?) | 21:26 |
| jelmer | jam, yeah | 21:26 |
| jam | wow, 1 day and already bug #261614 | 21:27 |
| ubottu | Launchpad bug 261614 in bzr "Stand-Alone version for 1.6 for Windows" [Undecided,New] https://launchpad.net/bugs/261614 | 21:27 |
| jelmer | jam, it still doesn't work for me though | 21:27 |
| jam | sombody is antsy | 21:27 |
| jam | Not sure I would claim that as a bug... | 21:27 |
| jam | Maybe I should mark it "won't fix" ;-) | 21:27 |
| luks | well, it's a missing feature :) | 21:28 |
| jam | ah, so wishlist then | 21:29 |
| evarlast | jam: thanks for the help. I thik paramiko was finding cygwin ssh before it was finding plink. I run in a cmd.exe instead of a cygwin shell and I was able to push my branch successfully. thank you so much for your help. | 21:29 |
| jam | mark1: bug 261614 is for you, btw :) | 21:29 |
| ubottu | Launchpad bug 261614 in bzr "Stand-Alone version for 1.6 for Windows" [Undecided,New] https://launchpad.net/bugs/261614 | 21:29 |
| evarlast | jam: this is the second time you were great help to me, so IMO, you are a selling point to use BZR over another DVCS :) | 21:30 |
| jam | thanks evarlast, always happy to help | 21:30 |
| jam | jelmer: You have 0.4.11-final now? | 21:49 |
| jelmer | jam: Yeah; no code changes though | 21:49 |
| jam | sure, but a new package | 21:49 |
| jam | hmm... it seems you haven't pushed your changes yet | 21:50 |
| james_w | thanks jelmer | 21:50 |
| jelmer | jam: yeah | 21:51 |
| jam | vila: just pointing you at something I thought would be good for your review: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20080718.152135.44280555651435908.Christophe.Troestler%40umh.ac.be%3E | 21:51 |
| jelmer | jam, I was waiting for gnome playground to do an import of evolution to see if the speed improvements really helped | 21:51 |
| jelmer | jam: Hopefully this means we can have 0.4.11 in Intrepid rather than having to request an exception for it later | 21:52 |
| === bob2_ is now known as bob2 | ||
| jelmer | jam: new 0.4.11 now pushed to bzr.d.o as well now | 22:02 |
| jelmer | jam, sorry, I wasn't trying to create more work for you... | 22:02 |
| james_w | jelmer: thanks for the upload | 22:04 |
| lifeless | jam: I'd like more feedback on log | 22:27 |
| james_w | jelmer: hey, what do you think to http://paste.ubuntu.com/40773/ ? | 23:10 |
| james_w | jelmer: not the changelog, but the actual patch. | 23:11 |
| jelmer | james_w, ah, I remember | 23:11 |
| james_w | sorry you're only getting it now, I should have pushed him more to do it at the time | 23:11 |
| jelmer | james_w, I encouraged that guy to submit it upstream, I think it's already been merged there (post 0.95 though) | 23:11 |
| james_w | ah, post 0.92 | 23:12 |
| james_w | *5 | 23:12 |
| jelmer | yep, it's already upstream | 23:12 |
| james_w | indeed, I've just grabbed a branch to submit it to you | 23:12 |
| james_w | cool, so you're happy for it to be in the Ubuntu package until the next release? | 23:12 |
| jelmer | -r597.1.1 | 23:12 |
| jelmer | james_w, yep, looks good to me | 23:13 |
| james_w | jelmer: great, thanks. I'll try harder to avoid this in future. | 23:14 |
| jelmer | james_w: Thanks | 23:14 |
| jam | jelmer: I'm missing a bzr-svn-0.4-11-1 tag | 23:15 |
| jelmer | james_w, Is seems to generally happen when people are not familiar with upstream | 23:15 |
| vreixo | hi guys! | 23:15 |
| vreixo | do any of you knwo how to sign a revision in bzr with a gpg key? | 23:15 |
| james_w | jelmer: yeah, and that's more of a problem in Ubuntu as there is less concentration on specific pacakges. | 23:16 |
| jelmer | jam: Sorry - should be there now | 23:16 |
| james_w | jelmer: I've done bzr, bzrtools, working on bzr-gtk, and wating for bzr-svn to hit the archive, is there anything I am missing? | 23:16 |
| jelmer | I've still got a bunch of sync requests open: | 23:17 |
| jelmer | bzr-avahi, bzr-stats, bzr-upload, bzr-dbus, bzr-cvsps-import | 23:17 |
| jelmer | it would be nice to have loggerhead in, once it hits experimental (not likely to happen today though) | 23:17 |
| jelmer | loggerhead is in NEW currently | 23:18 |
| jam | jelmer: there seems to be an "0.4.11-1" but not a "bzr-svn-0.4.11-1" | 23:18 |
| james_w | yeah, it's a bit late, otherwise we could have gone directly with loggerhead. | 23:18 |
| james_w | jelmer: have your requests been ACKed yet? | 23:18 |
| jelmer | james_w, yep | 23:19 |
| jelmer | jam, fixed | 23:19 |
| james_w | cool, so hopefully there will be a sync run tomorrow. | 23:19 |
| jelmer | Guess we can always request an exception for loggerhead, can we? | 23:21 |
| james_w | jelmer: we can | 23:21 |
| jelmer | Cool | 23:21 |
| james_w | jelmer: do you have a copy of the .dsc you dput for bzr-svn? | 23:22 |
| james_w | I want to check that it builds in Intrepid before filing the sync request | 23:22 |
| james_w | or if you have a chroot, could you test? | 23:22 |
| jelmer | james_w, http://samba.org/~jelmer/debian/experimental/bzr-svn_0.4.11-1.dsc | 23:23 |
| james_w | perfect, thanks | 23:23 |
| james_w | lifeless: hi. | 23:33 |
| jam | jelmer: so... I can't build multiple distro packages, because it always regenerates the orig.tar.gz | 23:33 |
| james_w | lifeless: do you feel like using your ubuntu-dev membership? | 23:33 |
| jam | How do I get it to re-use one it already built? | 23:33 |
| jelmer | james_w, I wonder if that's as hard as getting him to use his debian-dev membership ;-) | 23:34 |
| jelmer | jam: Run just debuild (with the tarball in the parent directory) | 23:34 |
| jam | jelmer: but I need to do it for 3 releases.... I get no help ? | 23:34 |
| james_w | ah, and we need a core-dev really, I assumed Rob was one. | 23:35 |
| jelmer | jam, this is the original reason I stopped uploading to ppa | 23:35 |
| jam | jelmer: It works fine if you use a tarball rather than a tree export | 23:36 |
| jam | I use it for bzr | 23:36 |
| jelmer | jam: You should be able to uncommit export-upstream in .bzr-builddeb/default.conf | 23:36 |
| jam | I just don't know how to trick bzr-builddeb into using it | 23:36 |
| jelmer | s/uncommit/uncomment/ | 23:36 |
| jelmer | james_w, Would it perhaps be an idea to skip export-upstream if there's a tarball already there? | 23:37 |
| james_w | jelmer: I was just going to say that it did that, but it doesn't make any sense | 23:37 |
| james_w | it could do, the reason it doesn't is if you set "export-upstream = branch" | 23:37 |
| james_w | then it doesn't know whether it should regenerate as the branch has moved on | 23:38 |
| james_w | it works fine if export-upstream-revision is set, assuming the revision history of the upstream branch doesn't change in a way to break that | 23:38 |
| jelmer | ah, right - or if you changed the tag set in export-upstream-revision | 23:38 |
| jelmer | hmm | 23:38 |
| james_w | yeah | 23:38 |
| james_w | it works for the magic case you added | 23:39 |
| vreixo | nobody knows how to sign revisions in bzr? | 23:41 |
| vreixo | is that supported? | 23:41 |
| jam | james_w, jelmer: What about this patch: http://rafb.net/p/yS3cLT40.html | 23:41 |
| AfC | There's no command to fork a file into two files (with common history as far as Bazaar is concerned, right?) | 23:41 |
| AfC | vreixo: sure it is | 23:41 |
| jam | It means if you do --export-upstream='' | 23:41 |
| jam | It overrides | 23:41 |
| jam | and says you don't want to export | 23:42 |
| jam | just use a tarball | 23:42 |
| jam | (rather than "accidentally" using the current directory) | 23:42 |
| vreixo | AfC: that is what we need (a bzr copy) | 23:42 |
| vreixo | AfC: do you know how to sign revisions? | 23:42 |
| james_w | jam: reasonable | 23:43 |
| pygi | vreixo, :) | 23:43 |
| james_w | not pretty, but reasonable | 23:43 |
| pygi | vreixo, you need to have patience :P | 23:43 |
| jam | james_w: well I could do "if export_upstream in (None, '')" if you prefer | 23:43 |
| vreixo | pygi: hi! | 23:43 |
| vreixo | I have... | 23:43 |
| james_w | jam: well I mean --export-upstream='' | 23:43 |
| pygi | vreixo, what are you trying to sign? xD | 23:44 |
| james_w | jam: also, your patch misses a test | 23:44 |
| jam | Well, the other is "--no-export-upstream" but it is a bit hard to wedge in | 23:44 |
| vreixo | none, I just want to know how to sign my commits... | 23:44 |
| lifeless | jam: minor rant on list; its not aimed at you, but its a reply to your comments so it might appear so - its not! | 23:44 |
| lifeless | james_w: hmm? | 23:44 |
| james_w | jam: --use-existing-tarball ? | 23:44 |
| jam | lifeless: thanks for the heads up | 23:45 |
| james_w | lifeless: we're trying to push bzr 1.6 and associated packages in to Intrepid, I'm after someone to confirm the sync requests so we don't miss the boat | 23:45 |
| lifeless | james_w: link me up baby | 23:45 |
| james_w | lifeless: we could do with a core-dev for bzr and bzrtools | 23:46 |
| lifeless | james_w: yes, I would like to be a core-dev | 23:46 |
| lifeless | ETIME | 23:46 |
| james_w | https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/261653 | 23:46 |
| ubottu | Launchpad bug 261653 in bzr-svn "Please sync bzr-svn 0.4.11 (universe) from Debian experimental (main)" [Wishlist,New] | 23:46 |
| james_w | https://bugs.edge.launchpad.net/ubuntu/+source/bzr-gtk/+bug/261645 | 23:46 |
| ubottu | Launchpad bug 261645 in bzr-gtk "Please merge bzr-gtk 0.95.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] | 23:46 |
| lifeless | james_w: I'll click through after brekkie | 23:46 |
| james_w | well, the second is an upload | 23:46 |
| james_w | thanks | 23:46 |
| rockstar | http://pyside.blogspot.com/2008/08/quick-hgbzr-timings.html | 23:49 |
| AfC | I take it that http://bazaar-vcs.org/BzrFileCopies implies that `bzr copy` does not yet exist? | 23:52 |
| lifeless | AfC: right, doesn't exist yet | 23:52 |
| AfC | lifeless: pity | 23:53 |
| AfC | lifeless: ok, thanks | 23:53 |
| jam | jelmer: bzr-svn-0.4.11-1 uploaded for ~gusty, ~hardy, and ~intrepid | 23:55 |
| jam | But "~intrepid" just failed to build | 23:55 |
| jam | http://launchpadlibrarian.net/17103846/buildlog_ubuntu-intrepid-lpia.bzr-svn_0.4.11-1%7Ebazaar1%7Eintrepid_FAILEDTOBUILD.txt.gz | 23:55 |
| james_w | jam: probably archive skew | 23:56 |
| jam | james_w: It seems "libsvn-dev" doesn't exist in intrepid | 23:56 |
| jam | james_w: it seems to say "libsvn-dev depends on libsvn1-dev but that package will not be installed" | 23:56 |
| jam | Why wouldn't it install the dependency? | 23:57 |
| jam | Do I just need to update the "Build-Depends: " to get it to work? | 23:57 |
| james_w | libsvn-dev 500 http://archive.ubuntu.com intrepid/main Packages | 23:57 |
| jam | james_w: Is that supposed to mean something to me? | 23:58 |
| jam | It looks like an apt source, I guess | 23:58 |
| jam | but the 500 is unknown | 23:58 |
| james_w | jam: rmadison is clearer | 23:58 |
| james_w | libsvn-dev | 1.5.1dfsg1-1ubuntu2 | intrepid | amd64, i386 | 23:58 |
| james_w | it was supposed to show that libsvn-dev does exist | 23:59 |
| james_w | I'm looking in to why it is uninstallable | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!