| glyph | If I'm working on one branch on a few different development machines, but I'm periodically rebasing it, is there a reasonable way to keep it in sync? | 00:08 |
|---|---|---|
| lifeless | pull ? | 00:09 |
| glyph | won't pulling fail if I've rebased on a different machine? | 00:09 |
| lifeless | if you add --overwrite, no | 00:17 |
| spiv | Hmm, BranchBuilder is just a bit more verbose than necessary | 02:38 |
| spiv | I think I'll try making the start_series() unnecessary. | 02:38 |
| lifeless | one way might be to glue that into setUp () | 02:39 |
| spiv | Hmm, perhaps. | 02:40 |
| spiv | The with statement would be nice to have :/ | 02:41 |
| spiv | Hmm, actually, in this specific case I don't need to call start_series at all, as I'm only using build_commit. | 02:41 |
| glyph | spiv: do you want a repo that can repro that bug mentioned above? I notice you commented on it a while ago | 02:41 |
| spiv | glyph: I should pester jelmer and/or jam | 02:42 |
| spiv | glyph: the cause of that bug is actually understood now I think | 02:42 |
| spiv | glyph: peitschie provided enough data privately that we diagnosed it, but the diagnosis ended up happening in private emails and not copied into the bug despite my nagging :( | 02:43 |
| spiv | glyph: it boils down to: the way bzr-svn regenerates bzr revs from an svn repo can vary in a way that violates assumptions in bzr | 02:46 |
| glyph | spiv: can you give me a hint as to _when_ this variation occurs? | 02:50 |
| glyph | I would very much like to continue using bzr as my svn client | 02:50 |
| glyph | but periodically having to trash all of my data is potentially a problem :) | 02:50 |
| spiv | glyph: ghost revisions | 02:51 |
| spiv | glyph: when the svn repo hasn't had all the bzr revs referenced pushed to it | 02:51 |
| spiv | glyph: then later gets some of those pushed | 02:51 |
| glyph | huh | 02:52 |
| glyph | I could swear that's not what happened here | 02:52 |
| spiv | glyph: it can change the metadata in other inventories that bzr-svn generates | 02:52 |
| spiv | Well, it might be a different bug, or my recollection of the diagnosis might be a bit off. | 02:52 |
| spiv | glyph: here's a test: | 02:52 |
| spiv | glyph: do you get an error when branching from the svn repo into an entirely new bzr repo? | 02:52 |
| glyph | no. | 02:53 |
| spiv | And if not, do you get an error when merging/pull between that new repo and a previous bzr repo that has some of the same revs. | 02:53 |
| glyph | yes? I think? | 02:53 |
| spiv | Ok, those are the expected answers :) | 02:53 |
| glyph | okay so my question is | 02:53 |
| glyph | what do I avoid doing? | 02:53 |
| spiv | If it's not the same bug it's certainly related. | 02:54 |
| glyph | The thing that confuses me is that I don't believe any of these bzr revs were ever pushed to svn | 02:54 |
| spiv | glyph: there's zero bzr metadata in your svn repo? | 02:54 |
| glyph | oh | 02:54 |
| glyph | there is some. | 02:54 |
| spiv | No bzr file-ids, no bzr rev-ids? | 02:54 |
| glyph | Should I go delete it all? | 02:54 |
| glyph | I tried to avoid any getting in there, but dash is always like "no, bzr-svn works great, I haven't seen a traceback in like a week" push push push | 02:55 |
| spiv | Well, if you delete it you'll have a different problem, but perhaps a better one. | 02:55 |
| spiv | You're using dpush or whatever the rebasing thingy is, IIRC? | 02:55 |
| dash | yeah i'm not a good neighbour | 02:55 |
| glyph | Personally yes | 02:56 |
| dash | OTOH i've been using bzr-svn in a different svn repo with no problems... but i'm the only bzr user there :) | 02:56 |
| glyph | spiv: this actually happened about 2 hours before I was going to decide that bzr-svn _did_ work well enough to start putting bzr metadata in Twisted's repository :) | 02:56 |
| spiv | So I think the effect that has is that it basically rebases the local bzr revs after the push to svn... the key thing here is that you have a bzr rev that is meant to be equivalent to an svn rev. | 02:56 |
| glyph | (we recently configured trac to be amenable) | 02:56 |
| glyph | spiv: right. it's like rebase++ though, right? because it has a bit more information than rebase | 02:57 |
| glyph | (I say this because I tried some experiments with 'rebase' and then 'push' and the effects were radically different) | 02:57 |
| spiv | And if you delete the bzr metadata from svn, that bzr rev won't match anymore. I don't know enough about the exact details of bzr-svn and dpush to say what will happen, it might be minor irritant, or it might be an equivalently bad situation to the current one. | 02:58 |
| spiv | If the effect is "after stripping bzr properties bzr-svn will generate bzr revs with the same id as before but different contents", you have basically the same class of problem. | 02:59 |
| spiv | If the effect is "after stripping bzr-svn generates entirely new bzr revs with new ids", then you just have basically a rebase situation, where there's a conflicting alternate history, but at least no actual violation of bzr's data model. | 03:00 |
| spiv | FWIW, my current guess is that bzr-svn can be fairly easily fixed to not vary the way it generates this data. | 03:01 |
| spiv | Hmm, I should get some lunch. | 03:02 |
| glyph | OK I will have more questions once you have lunched :) | 03:02 |
| peitschie | glyph: you still around? | 03:22 |
| glyph | peitschie: hello! | 03:25 |
| peitschie | glyph: hi :)... did you have any joy getting the answers you were looking for (i.e., bzr-svn with multiple devs using bzr)? | 03:27 |
| glyph | peitschie: Sort of :) | 03:31 |
| glyph | I'm about to give it a try and see what happens | 03:31 |
| peitschie | glyph: cool. let me know if things don't go well for you as we have a process here that is working ok for several devs... but it requires a shared network repository of some sort and a bit of careful planning (robust enough once the devs are trained tho lol) | 03:36 |
| spiv | glyph: so, more questions? | 04:45 |
| glyph | spiv: well, I can't reproduce the problem without my special messed-up repo | 04:49 |
| glyph | so I'm going to assume that I did something bad | 04:49 |
| fullermd | That's my motto. | 04:50 |
| peitschie | lol fullermd | 05:09 |
| peitschie | glyph: the problem is actually reasonably straight forward to reproduce if you check out the bug report :) | 05:09 |
| peitschie | glyph: having said that tho... you generally need to separate devs (or deliberately be working on two different repos) to trigger it | 05:10 |
| peitschie | glyph: main reproduction steps are: | 05:12 |
| peitschie | 1. dev1 merges branch into svn | 05:12 |
| peitschie | 2. dev2 updates from svn | 05:12 |
| peitschie | 3. dev2 attempts to merge change directly from dev1's branch somewhere | 05:12 |
| peitschie | 4. Profit! | 05:12 |
| glyph | peitschie: yeah, that's definitely not what I was seeing | 05:20 |
| glyph | basically what I saw was | 05:20 |
| glyph | I got a bzr branch from svn trunk on two different machines | 05:20 |
| glyph | made a bzr branch of that on one | 05:20 |
| glyph | checked in one revision to that branch | 05:20 |
| glyph | and then attempted to get the branch from another machine | 05:21 |
| glyph | but when I got new repos on the defective machine and tried again, everything worked. | 05:21 |
| spiv | glyph: "I got a bzr branch from svn trunk on two different machines" — did you get both those branches from SVN at the same time? | 05:22 |
| peitschie | glyph: and it will.. up until the other machine checks in again | 05:22 |
| peitschie | glyph: in _theory_ (i.e., if this is the same bug :) ), wen the other machine checks in ,and the first updates again... any attempts to trade between them will break once again | 05:22 |
| glyph | spiv: No. I'm not really sure when I updated svn from each. I _am_ pretty sure that no bzr-props-adding activity was going on between them though. | 05:24 |
| spiv | glyph: interesting, but other svn activity may have gone on? | 05:24 |
| dash | weird, i've never seen this | 05:25 |
| spiv | glyph: btw, if you want to find out if a set of repositories have this inconsistency waiting to bite you: | 05:25 |
| glyph | spiv: Yes. | 05:25 |
| dash | i've seen some odd messages from bzr-svn use from time to time, but it's always gone away after doing a pull from svn into a new branch in my repo, then pulling from the fresh branch into my normal one | 05:26 |
| spiv | glyph: grab lp:~spiv/bzr-crosscheck/integration and install it to ~/.bazaar/plugins/crosscheck, then you can do "bzr cross-check REPO_A REPO_B ..." | 05:26 |
| glyph | spiv: what does that do? | 05:26 |
| spiv | glyph: (that plugin almost certainly has rough edges, but it's one of the things I've been using to diagnose this sort of problem) | 05:27 |
| glyph | Oh, hrm | 05:27 |
| glyph | Here's an interesting clue. | 05:27 |
| glyph | our repo has 2 URIs | 05:27 |
| spiv | glyph: it basically finds all the inventories that exist in more than one repo (out of the N repos you pass it) | 05:27 |
| glyph | http://svn.calendarserver.org/repository/calendarserver and http://svn.macosforge.org/repository/calendarserver | 05:28 |
| spiv | glyph: and then compares them to see if they have the same contents | 05:28 |
| spiv | Because bzr assumes that records with the same key in multiple repositories have the same contents. | 05:29 |
| spiv | And if that assumption is violated then problems like this are to be expected :( | 05:29 |
| glyph | spiv: OK! | 05:29 |
| * spiv notices he has some uncommitted, experimental improvements to bzr-crosscheck. He commits and pushes them up to a new branch... | 05:34 | |
| spiv | Wow, where did the week go? | 08:05 |
| mgz | somewhere in america I think spiv. | 08:12 |
| yann2 | hello! When a developer pushes to a branch, the files are set with permissions = 644 .... How can I change the umask so I get 664? | 10:02 |
| Tak | usually the default umask on a unix box is set in /etc/profile | 10:09 |
| Tak | or you can set the umask for a given user in its ~/.profile | 10:10 |
| Tak | now what's the best way to test a trunk branch of bzr-explorer (when I already have one installed with my system bzr)? | 10:10 |
| GaryvdM | Tak: bzr branch lp:bzr-explorer ~/bzr-explorer | 10:12 |
| GaryvdM | Tak: export BZR_PLUGINS_AT=explorer@/home/tak/bzr-explorer | 10:13 |
| Tak | aha | 10:13 |
| ChrisCauser | Hello everyone. Have I come to the right channel for bzr-svn support? | 10:15 |
| GaryvdM | ChrisCauser: Yes | 10:16 |
| ChrisCauser | Thank you. I am not having a problem as such, merely an annoyance. | 10:16 |
| ChrisCauser | I have an svn repo with different branches. I have two mirrored in a local bzr repository | 10:17 |
| ChrisCauser | (As in I checkout'd them, not branched them) | 10:17 |
| GaryvdM | BZR_PLUGINS_AT has made my life much easier. Before, I had to use a horrible mixture of lightweight checkouts, treeless branches, bzr switch, and BZR_PLUGIN_PATH | 10:17 |
| GaryvdM | Kudos vila! | 10:17 |
| Tak | that does sound horrible | 10:17 |
| ChrisCauser | I make changes in the DEV branch just fine, and merge them into my trunk branch | 10:17 |
| * Tak add kudos as well | 10:18 | |
| ChrisCauser | The only problem is I cannot pull from DEV to trunk | 10:18 |
| ChrisCauser | I get a diverged error. | 10:18 |
| GaryvdM | ChrisCauser: Yes - you probably need to merge, not pull | 10:18 |
| ChrisCauser | I know the histories are not in sync because of the merges I have done in the past, but is there a way to put that behind me (as it were) and allow pulling | 10:19 |
| ChrisCauser | Because a merge squashes it for SVN | 10:19 |
| peitschie_ | ChrisCauser: is the dev branch an actual svn branch? | 10:21 |
| GaryvdM | ChrisCauser: maybe pull trunk into dev. I would recomend doing "bzr qlog trunk dev" before and after so that you get an understanding of what it does. | 10:21 |
| ChrisCauser | Peitschie: Yes, it is. I know the squash merge is no worse than what SVN does naturally, but I just wanted to see all the commits I've made in trunk. | 10:23 |
| ChrisCauser | GaryvdM: Thank you for the advice. I will give that a go now. | 10:23 |
| ChrisCauser | GaryvdM: I am afraid it does not pull because they have diverged as well. | 10:24 |
| GaryvdM | ChrisCauser: qlog should show you how they have diverged. maybe merge dev in to trunk, then pull trunk into dev. | 10:26 |
| ChrisCauser | GaryvdM: According to qlog, the diversion is because of the last merge to trunk I made. Other than that it looks fine. From the looks of how bzr is handling the merges, this will always be a problem no matter how I merge it. | 10:30 |
| peitschie_ | ChrisCauser: I fear that there is no easy way to get all commits in either direction.. at least, not when the dev branch is in svn as well | 10:31 |
| peitschie_ | ChrisCauser: you might be interested in the rebase plugin... but really you need your dev branch in bzr for that functionality | 10:31 |
| ChrisCauser | peitschie_: That's what I feared. Again, this isn't a problem. It's merely something that's been bugging me. | 10:33 |
| ChrisCauser | Thank you all for your help. Merging I guess is the only way forward. | 10:34 |
| peitschie_ | can anyone help me with installing the monodevelop-bzr plugin with the monodevelop trunk? | 13:34 |
| Tak | yes, I can :-) | 13:34 |
| peitschie_ | :D | 13:34 |
| peitschie_ | yas! | 13:35 |
| peitschie_ | i finally got everything compiled and installed | 13:35 |
| peitschie_ | wat's the next step? | 13:35 |
| Tak | ok, the easiest way is to add the community repo from addins.monodevelop.com using MD's addin manager | 13:36 |
| peitschie_ | i've tried the instructions from http://wiki.bazaar.canonical.com/MonoDevelop | 13:36 |
| peitschie_ | and it crashes wen i load it | 13:36 |
| Tak | yes, those need to be updated :-/ | 13:38 |
| peitschie_ | so i'm assuming i can branch to within the monodevelop source (i.e., extras) and rebuild it there somehow? | 13:39 |
| Tak | even easier | 13:39 |
| peitschie_ | yay :D | 13:39 |
| Tak | if you add http://addins.monodevelop.com/Alpha/Linux/master using the addin manager | 13:40 |
| Tak | you should be able to install it directly from there | 13:41 |
| Tak | be sure to install a version from the 2.5 series if you're using MD master | 13:41 |
| peitschie_ | mm | 13:42 |
| peitschie_ | i must have done something wrong | 13:42 |
| peitschie_ | that added and installed ok | 13:43 |
| peitschie_ | but still crashes | 13:43 |
| Tak | then restart MD | 13:43 |
| Tak | well | 13:43 |
| Tak | make sure you uninstall the other addin as well | 13:43 |
| peitschie_ | ok... it's working a little | 13:45 |
| peitschie_ | annotate shows log lol | 13:45 |
| peitschie_ | i think i have an off-by-one error somewhere here | 13:45 |
| Tak | heh...MD master may occasionally have silly bugs ;-) | 13:46 |
| peitschie_ | hehe... if it's not bleeding it aint fresh enough! | 13:46 |
| === Meths_ is now known as Meths | ||
| mwhudson | 1073kB 29kB/s / Fetching revisions:Inserting stream:Estimate 5736/2478 | 14:41 |
| mwhudson | this doesn't seem quite right | 14:41 |
| mssever | I need to get a list of filesnames that have been modified or added since a particular revision, and a list of filenames that have been deleted. How can I do that? | 15:04 |
| LeoNerd | bzr stat -r123 | 15:05 |
| mssever | Thanks. | 15:05 |
| mssever | Somehow I missed that in the docs. It works OK. | 15:06 |
| LeoNerd | Mm.. I find it's a lot like Lego. A set of commands, a set of options... Hard to document every possible combination of options on commands. | 15:08 |
| poolie | poolie_droid, hello? | 15:47 |
| poolie_droid | Hi there | 15:48 |
| GaryvdM | mwhudson: You are not the only one to have seen that - http://osdir.com/ml/bazaar/2010-10/msg00381.html | 15:48 |
| GaryvdM | mwhudson: so I think a bug report is in order. | 15:49 |
| poolie | hi gary | 15:50 |
| GaryvdM | Hi poolie | 15:50 |
| GaryvdM | How has uds been so far? | 15:50 |
| poolie_droid | excellent, bit manic though | 15:55 |
| poolie_droid | i hope we can invite you to the next one in Europe in May | 15:55 |
| GaryvdM | :-) | 15:55 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| rubbs | bzr: ERROR: Failed to rename .../dev/www/login/index.php to .../dev/.bzr/checkout/pending-deletion\new-16: [Error 5] Access is denied <- coworker gets this error when trying to merge in his changes into the dev branch. Permissions problem? | 18:48 |
| rubbs | the weird thing is that I did a chmod -R 775 on the whole repo and double checked to make sure he was in the right group | 18:49 |
| beuno | rubbs, yes, in the .bzr/* dir | 18:49 |
| rubbs | k. I'll double check, but I thought I did a recursive group change and chmod 775 on it | 18:49 |
| rubbs | ok I did a chmod -R g+rwxs and chgrp -R staff on the .bzr directories on each of the branches, the .bzr dir in the shared repo location, and on all the bound branch locations, but I'm still getting that access denied error | 19:05 |
| rubbs | could it be he's doing this over a mounted sshfs? | 19:06 |
| rubbs | Ok, can someone help me figure this out. I've pasted the .bzr.log messages into this paste: http://paste.ubuntu.com/522232/ I also added a ls -Rlh on the .bzr directory of the /dev/ branch. both user1 and user2 are in the staff group. | 19:27 |
| === Meths_ is now known as Meths | ||
| rubbs | hmmm... looks like it's something with the bound branch. once I unbound the branch everything worked fine | 19:52 |
| === mtaylor_ is now known as mtaylor | ||
| poolie | hi there vila | 22:06 |
| poolie_droid | Hi vila, everyone | 22:16 |
| poolie_droid | Hi AfC | 22:36 |
| fullermd | The machines! They're taking over! | 22:37 |
| poolie_droid | :) | 22:38 |
| poolie_droid | *zap* | 22:38 |
| AfC | fullermd: it's ok. Droids can't think | 22:39 |
| fullermd | That's just what they WANT you to think. | 22:40 |
| glen | i created tag wrong, now i can fix it locally but i fail to push it back to launchpad | 23:25 |
| glen | complains on conflicting tags and i can't resolve that | 23:26 |
| fullermd | Does --overwrite make it force tags? | 23:30 |
| * fullermd doesn't remember. | 23:30 | |
| glen | boverwrite to which command? push? | 23:34 |
| glen | i can fix locally ok, problem is that it won't go "up". i.e bzr push does not replicate the fixed tag, instead it aborts on conflict error | 23:34 |
| fullermd | Yah. | 23:34 |
| glen | ok thanks | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!