| libertas | hi, I restored a backup and am not able to issue `bzr log` for example | 00:20 |
|---|---|---|
| libertas | I get bzr: "ERROR: Not a branch:..." | 00:20 |
| libertas | Everything I tried didn't work, what can I do? | 00:21 |
| libertas | This working tree directory has a .bzr directory and the parent directory has the repo with its .bzr directory as well | 00:21 |
| spiv | Does 'bzr info' report anything helpful? | 00:32 |
| spiv | Do you have a .bzr/branch directory? What files and directories does it contain? | 00:32 |
| poolie | libertas, maybe the permissions are wrong? | 00:33 |
| libertas | poolie: they're fine... | 00:38 |
| libertas | bzr check | 00:39 |
| libertas | No working tree found at specified location. | 00:39 |
| libertas | No branch found at specified location. | 00:39 |
| libertas | No repository found at specified location. | 00:39 |
| poolie | what does 'ls -o .bzr' show | 00:39 |
| libertas | repo$ ls -o .bzr | 00:42 |
| libertas | shows repository | 00:42 |
| libertas | main$ ls -o .bzr | 00:43 |
| libertas | shows branch & checkout | 00:43 |
| libertas | all with owner my user | 00:45 |
| spiv | what does 'find .bzr -type f' show? (pastebin it) | 00:54 |
| spiv | In short, bzr expects a branch to have .bzr/branch-format and .bzr/branch/format and a few other files/dirs, similar for repositories and checkouts. | 00:54 |
| spiv | But rather than guess one-by-one which part might be missing or unreadable or whatever it's probably quickest to just show us exactly which files are present. | 00:55 |
| libertas | http://pastebin.com/vmb79skT | 00:57 |
| libertas | and inside main: http://pastebin.com/VTbTYFgM | 00:58 |
| spiv | Lots of stuff seems to be missing there | 00:59 |
| spiv | Notably the .bzr/branch-format and .bzr/branch/format files | 00:59 |
| spiv | And I didn't see .bzr/repository/format in the first one either | 00:59 |
| libertas | no, it's not there | 00:59 |
| spiv | Compare what you'd see from a fresh 'bzr init-repo' or 'bzr init' | 01:00 |
| spiv | So your restored backup appears to be missing a fair few things. Fortunately it looks like you *might* have all the revision history still | 01:01 |
| libertas | in another backup (older) I get http://pastebin.com/0a2kRsNp | 01:02 |
| spiv | If you make a fresh repository with init-repo, and copy the pack-names and packs/* contents into it, you may have a functioning repo with the key data, try browsing it with 'bzr qlog' or similar. | 01:02 |
| libertas | spiv: thank you very much, I'll try that | 01:02 |
| spiv | Right, that older backup looks like it may have a valid (but empty?) repository | 01:03 |
| spiv | And still a completely broken branch/checkout | 01:03 |
| spiv | Once you get running again I'd be very worried about your backup system | 01:03 |
| libertas | :-) I messed up a bit with dropbox, that's why I'm running into problems now. | 01:05 |
| libertas | But thank you again! | 01:05 |
| spiv | You're welcome, glad I could help. | 01:06 |
| poolie | libertas, what did you use for the backups? | 01:06 |
| poolie | thanks spiv | 01:06 |
| spiv | Oh! I should also say, the .bzr/branch/last-revision file from the older backup may be helpful | 01:06 |
| spiv | In reconstructing a reasonably current branch — again, 'bzr init' a branch and copy the last-revision from the backup into place | 01:07 |
| spiv | Or just 'bzr pull -r REVID' if you find the right revision via 'bzr qlog' or similar | 01:08 |
| libertas | poolie: the problem was that during the restoring I messed with dropbox, it's not the backup tool I used: rdiff-backup | 01:08 |
| libertas | spiv: next time I'll let you know if I could manage save history. | 01:09 |
| libertas | have to go now. Bye! | 01:09 |
| smspillaz | hello everyone - thumper asked me to ask here if / how it is possible to merge several bzr repos into one repo while keeping all the history | 03:54 |
| smspillaz | soooo ... how would I do that :) | 03:54 |
| poolie | hi smspillaz | 03:54 |
| poolie | tell me more about your case? | 03:54 |
| smspillaz | hello :) | 03:54 |
| smspillaz | right so | 03:55 |
| smspillaz | I have a whole bunch of repos in launchpad for all the individual compiz plugins (don't ask why, complicated git/bzr import sync stuff), which I now want to move into one big repo, so compiz-plugins | 03:55 |
| smspillaz | I'd like to avoid just copypasting them into a repo and starting from there and preferably try and keep all the history for the individual plugins | 03:56 |
| smspillaz | so when you view the history, it will be in linear order for every single commit made across each branch | 03:56 |
| poolie | do you want to put them into subdirectories of that tree? | 03:57 |
| poolie | or should they mesh together at the top? | 03:57 |
| smspillaz | poolie: subdirectories, preferably | 04:00 |
| spiv | Hmm, I think the merge_into plugin is out-of-date, unfortunately (which would have made doing this pretty convenient) | 04:04 |
| spiv | (It wouldn't be hard to update it to use the MergeIntoMerger that was added for use by bzr-builder though) | 04:05 |
| smspillaz | well, it should also be possible to use some bzr foo to collect all the revisions and then apply them bottom to top | 04:06 |
| spiv | It wouldn't interleave the commits the way you want | 04:06 |
| poolie | i was going to suggest merge-into too | 04:06 |
| spiv | But then you would have the original commit history intact, and could reconstruct that view (by e.g. forcing a log sorted by date, or something) | 04:06 |
| poolie | it will still look like they merged | 04:07 |
| spiv | In lieu of merge-into being current, you could use a bzr-builder recipe... | 04:07 |
| smspillaz | haha probably ;-) | 04:07 |
| poolie | spiv do you know if merge-into is very out of date or just trivially? | 04:09 |
| mwhudson | you could install an old bzr somewhere so you could use merge-into? | 04:09 |
| smspillaz | should I give bzr builder a try ? | 04:09 |
| poolie | smspillaz, i think you should try bzr-merge-into and see if it fails | 04:10 |
| poolie | and file a bug if so | 04:10 |
| smspillaz | ok :) | 04:10 |
| poolie | perhaps we can easily update it | 04:10 |
| spiv | poolie: IIRC very; relies on inventory mutation stuff that fails with CHKs | 04:10 |
| spiv | poolie: but the tricky bits are all implemented in bzrlib now | 04:11 |
| smspillaz | poolie: failing that, what do you think of a pythong script to collect all the revisions and then apply them? | 04:11 |
| spiv | poolie: so, it's both very out of date and trivially broken :) | 04:11 |
| smspillaz | since I can do that (limited experience with bzr) | 04:11 |
| spiv | poolie: I *think* if you look in the history of my MergeIntoMerger work you'll actually find a working merge-into command that we decided against adding to core | 04:12 |
| spiv | poolie: but you could probably extract it back into the plugin cheaply | 04:12 |
| spiv | poolie: (or maybe the plugin did get updated since I last looked!) | 04:12 |
| spiv | poolie: basically, if you have bzr-search working, I'd see if searching for cmd_merge_into finds anything :) | 04:13 |
| poolie | smspillaz, if you want to try that script it would be good | 04:13 |
| poolie | you could do it inside bzr-rewrite | 04:13 |
| poolie | which should give you some framework | 04:13 |
| poolie | it would be useful to have in general | 04:13 |
| smspillaz | poolie: incidentally, I'm kind of in favor of using recipies to do this, although I guess it wouldn't sort the history | 04:14 |
| spiv | smspillaz: to be honest, I'd be inclined to just take the merge-into style combining rather than rewriting. Partly because it'll probably be much easier, but also because it'll ease merging any branches that people made off the old branches. | 04:15 |
| poolie | +1 | 04:15 |
| smspillaz | indeed | 04:15 |
| smspillaz | will make bisection a bit annoying, but meh | 04:15 |
| poolie | mm | 04:20 |
| smspillaz | hmm, fun bzr-builder doesn't seem to keep the history, looks like the python script is the way to go | 04:20 |
| poolie | yes, i thought it only built trees | 04:20 |
| poolie | so smspillaz, are you reasonably unblocked? | 04:53 |
| lifeless | poolie: have you tried switch -f ? | 05:02 |
| lifeless | poolie: its meant to ignore NBE | 05:02 |
| poolie | lifeless, ok, thanks | 05:24 |
| poolie | yes that does fix it | 05:27 |
| smspillaz | poolie: yeah :) | 05:32 |
| mgz | morning all | 07:59 |
| vila | hi all | 08:00 |
| poolie | hi all | 08:01 |
| poolie | vila i see there was a pristine-tar failure on glade | 08:02 |
| poolie | mgz, hi? | 08:02 |
| jelmer | 'morning | 08:02 |
| poolie | suggests the upgrade may have been bad | 08:03 |
| poolie | hi jelmer | 08:03 |
| mgz | hey poolie | 08:03 |
| vila | poolie: me too ;) I suspect packagers changed the way they use xz and now requires a more recent version | 08:03 |
| vila | poolie: i.e. the pristine-tar upgrade addressed some issues but not all | 08:04 |
| poolie | ok | 08:04 |
| poolie | i filed https://bugs.launchpad.net/udd/+bug/937555 | 08:05 |
| ubot5 | Ubuntu bug 937555 in Ubuntu Distributed Development "pristine-tar error" [Undecided,New] | 08:05 |
| bialix | mgz, wgz: around? | 08:19 |
| wgz | bialix: yup | 08:19 |
| bialix | hi | 08:20 |
| bialix | I'm going to release bzr-explorer today | 08:20 |
| bialix | this morning I simply disabled filesystemwatcher in explorer for windows | 08:20 |
| bialix | I have no resources to find and fix underlying issue | 08:21 |
| wgz | yeah, I've got a similar branch here | 08:21 |
| bialix | which one? | 08:21 |
| wgz | but haven't yet got a polished version which will do what the watcher intends | 08:21 |
| bialix | I just made a Fake watcher class which does nothing | 08:22 |
| bialix | ok, I hope my fake won't make things worse at least | 08:23 |
| poolie | bialix, (like i said on the list) i think disabling it is good | 08:23 |
| poolie | there are a few bugs about different impacts of it | 08:23 |
| bialix | hi poolie | 08:23 |
| poolie | hi :) | 08:24 |
| bialix | maybe I haven't read your message yet | 08:24 |
| bialix | poolie: actually I'm very sad about the current status of bzr-explorer | 08:25 |
| bialix | it just stand still after Ian | 08:26 |
| bialix | (sigh) | 08:27 |
| wgz | bialix: yes, I agree | 08:34 |
| === mthaddon` is now known as mthaddon | ||
| === lool- is now known as lool | ||
| poolie | mgz, hi, can i call you? | 09:22 |
| mgz | poolie, sure, mumble though? I have more audio luck up here | 09:23 |
| poolie | that's ok, sure | 09:23 |
| mgz | ...and mumble forgot the settings atfer upgrade, but am on now | 09:27 |
| === yofel_ is now known as yofel | ||
| hrw | hi | 10:36 |
| hrw | again I have merge problem: http://pastebin.com/8GLTQw9L | 10:36 |
| jelmer | hrw: the two branches are unrelated it seems? | 10:37 |
| hrw | I pulled branch long time ago, did one change and forgot about it. today I did 2 more commits and I am unable to merge it according to bzr. fun is that there should not be even file conflicts in merge | 10:38 |
| jelmer | hrw: you can forcibly merge them with "bzr merge -r0..-1" | 10:38 |
| hrw | jelmer: they are same branch | 10:38 |
| hrw | push branch: bzr+ssh://bazaar.launchpad.net/~hrw/linaro-toolchain-recipes/backport-ppa-and-generic-tarball/ | 10:38 |
| hrw | parent branch: bzr+ssh://bazaar.launchpad.net/%2Bbranch/linaro-toolchain-recipes/ | 10:38 |
| hrw | submit branch: bzr+ssh://bazaar.launchpad.net/~linaro-maintainers/linaro/cross-toolchain-scripts/ | 10:38 |
| jelmer | hrw: note that "bzr missing" and "bzr merge" seem to use different locations | 10:39 |
| hrw | jelmer: I wonder why each time when I have merge problems with bzr it looks like 'who has the right (me or bzr)' question | 10:40 |
| hrw | jelmer: why? | 10:40 |
| hrw | jelmer: why different I meant | 10:42 |
| jelmer | hrw: there is a difference between the parent and merge locations - the parent is supposed to the branch your branch was created from, the merge location is where you submit to | 10:46 |
| jelmer | hrw: usually they're the same - you can always specify ":parent" as the location if you want to be sure you use one | 10:46 |
| hrw | "bzr merge :parent" merged with conflicts in just removed dir ;D | 10:48 |
| hrw | eh. but did in reverse - merged upstream into mine. | 10:51 |
| hrw | screw it, will erase and apply changes one by one instead | 10:51 |
| jelmer | hrw: right, that's what merge does - it merges the specified branch into the current one. That's the same in all VCSes I think ? | 10:51 |
| hrw | jelmer: you know, I am used to git more then to bzr. and 'bzr log' which hides merged commits by default scaries me ;) | 10:53 |
| hrw | or: I wanted rather rebase then merge my changes | 10:54 |
| jelmer | hrw: fwiw 'bzr log -n0' shows all revisions | 10:55 |
| hrw | I know | 10:55 |
| jelmer | mgz: ? | 11:38 |
| wgz | hey | 11:38 |
| jelmer | what, you're not working ? :P | 11:40 |
| * jelmer had a query open with the other mgz :) | 11:40 | |
| hrw | bye | 11:43 |
| wgz | jelmer: trying to do installers for 2.5b6 quickly | 11:49 |
| wgz | and realised doing the notes... I'd completely forgotten to write code to bundle the certs | 11:49 |
| mgz | so there goes 'quickly' | 11:50 |
| vila | mgz: get back quickly by disabling cert checks ;) | 11:53 |
| vila | mgz: the patch has landed on 2.5.0 anyway | 11:54 |
| mgz | vila: okay, will apply that on top | 11:56 |
| === mathrick__ is now known as mathrick | ||
| mlischke1 | hi, got a problem with bzr rebase, can someone help please? | 13:05 |
| mlischke1 | the branch is diverged after the rebase and I cannot push anything | 13:06 |
| mlischke1 | (this was a freshly clone feature branch I want to rebase with the main dev branch) | 13:07 |
| jelmer | hi mgz | 13:22 |
| jelmer | sorry mgz | 13:22 |
| jelmer | hi mlischke1 | 13:22 |
| jelmer | mlischke1: what are you trying to do exactly? | 13:22 |
| mlischke1 | jelmer, quite simple, I have a feature branch I want to rebase | 13:23 |
| mlischke1 | the feature branch was cloned from the main branch | 13:24 |
| mlischke1 | now I pushed everything so the feature branch was clean, then bzr rebase main-branch-url | 13:24 |
| mlischke1 | got a conflict, fixed it, bzr rebase-continue, all done | 13:24 |
| mlischke1 | now I cannot push because the branch is diverged | 13:25 |
| mlischke1 | I cannot pull, I cannot commit (as there isn't anything to commit) | 13:25 |
| mlischke1 | what else can I do now? | 13:25 |
| jelmer | mlischke1: why can you not pull ? pull should be reporting there is nothing to pull | 13:26 |
| mlischke1 | no it says the branches have diverged, I should use missing to see what is missing and merge to reconcile | 13:28 |
| mlischke1 | but what shall I merge? I have nothing to merge | 13:28 |
| jelmer | mlischke1: in that case it sounds like rebase hasn't finished succesfully | 13:28 |
| jelmer | mlischke1: what does 'bzr missing' say the difference between the branches is? | 13:29 |
| mlischke1 | hmm, there wasn't any error message, all the csets have been committed (+ commit mail sent) and that#s it | 13:29 |
| mlischke1 | it's a lot, but it looks as if anything is missing that I pushed to the feature branch + what was pushed in the meantime to the main branch | 13:30 |
| jelmer | mlischke1: there were changes to the main branch after the rebase? | 13:31 |
| mlischke1 | no | 13:32 |
| mlischke1 | there where changes while I worked in the feature branch | 13:32 |
| mlischke1 | but today there haven't been any changes there | 13:32 |
| jelmer | mlischke1: where are those revisions from the mainline showing up in the bzr missing output? | 13:33 |
| jelmer | mlischke1: can you perhaps try running 'bzr rebase' again? If it was successful earlier it should be a no-op | 13:36 |
| === Quintasan_ is now known as Quintasan | ||
| mlischke1 | jelmer, they are mixed, the first 6 are from the feature branch, then a lot from main and at the end again feature branch csets | 13:36 |
| mlischke1 | sure, let me try | 13:36 |
| jelmer | mlischke1: so some of the revisions are appearing twice? | 13:36 |
| mlischke1 | right, redoing the rebase is a noop | 13:37 |
| mlischke1 | yes, seem to be duplicated | 13:37 |
| mlischke1 | actually it says I have 47 extra revisions and 6 missing revisions | 13:38 |
| mlischke1 | the 6 missing are part of the 47 | 13:38 |
| mlischke1 | (so these are duplicated) | 13:38 |
| mlischke1 | the list of extra revisions (whatever that means) seems to be what the branch should look like after the rebase | 13:39 |
| mlischke1 | jelmer, just in case it matters, the feature branch was cloned on our server from the mainline and then I cloned both to my local disc | 13:45 |
| mlischke1 | the rebase was done against the server, not the local clone | 13:46 |
| === yofel_ is now known as yofel | ||
| jelmer | mlischke1: it sounds as if you have the original copy of the feature branch revisions in one branch and also rebased elsewhere | 13:46 |
| mlischke1 | (so I rebase a clone of a clone if you want so) | 13:46 |
| mlischke1 | hmm, that brings me to a thought | 13:47 |
| jelmer | are you pushing to the same locatin as you're pulling from/rebasing against? | 13:47 |
| mlischke1 | because when I wanna push I push to the clone on the server, which is not rebased | 13:47 |
| mlischke1 | yes, that must be it, I need to rebase the clone on the server instead | 13:48 |
| mlischke1 | grr, can't test on the server as the rewrite plugin is not installed there | 13:52 |
| mlischke1 | jelmer, I'm just wondering if that scenario is something I can use rebase at all? | 13:56 |
| mlischke1 | because when I rebase the repo on the server and then try to pull it will like give conflicts with my local copy as the revsions are reordered | 13:57 |
| mlischke1 | s/like/likely | 13:57 |
| jelmer | mlischke1: a good rule of thumb for rebasing in general is that you should never rebase anything that has been shared | 13:58 |
| mlischke1 | yes, I know, but actually this rule should be: you cannot rebase a shared repo :-) | 14:00 |
| mlischke1 | this was the first time I tried that, 3 hours wasted, but something new learned | 14:00 |
| mlischke1 | thanks for your help jelmer, much appreciated | 14:00 |
| jelmer | mlischke1: the fact that it's a shared repository shouldn't matter | 14:01 |
| jelmer | mlischke1: but perhaps I'm not entirely following what you're trying to do ? | 14:01 |
| mlischke1 | To me it appears clear now, as I tried to rebase a clone of a clone and then tried to push the changes to the original clone (which is not rebased) | 14:02 |
| mlischke1 | no wonder this gives problems | 14:02 |
| jelmer | mlischke1: ah, you mean a branch that was shared rather than a "shared repository" (which has a different meaning in bzr terminology) | 14:03 |
| mlischke1 | I cannot rebase the original clone either (mostly because the necessary plugin is missing) but I think it would also produce problems when I pull after that, as the order of the revisions have changed then and the local cannot do relative changes to previous revisions | 14:03 |
| mlischke1 | oh | 14:04 |
| mlischke1 | for me a repository and a branch are the same, sorry :-) | 14:04 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| cahewson | is there a global veriable for release number so it can be used in source? | 20:56 |
| jelmer | cahewson: yes, in the bzrlib module | 20:57 |
| lifeless | bzr revision-info may help you | 20:57 |
| lifeless | jelmer: I suspect cahewson wants a tree signature, for stamping builds | 20:57 |
| jelmer | I was thinking the version string of the bzr release he is using | 20:58 |
| lifeless | cahewson: also bzr version-info can extract a bunch of data to json / python etc, for stamping builds | 20:58 |
| lifeless | cahewson: but this all depends on what you want to achieve ;) | 20:58 |
| cahewson | i have rebuilt from trunk several times on various hosts. all the grub-install -v output give is 1.99 | 21:02 |
| lifeless | cahewson: so, I think you mean to say that you are working on grub2, which you have obtained from bzr, and would like to change it to make the version number depend on the code you have in front of you ? | 21:20 |
| m1sc | how could i prevent users from pushing to a shared repos root? | 22:01 |
| spiv | k | 22:14 |
| jelmer | hi spiv :) | 22:17 |
| jelmer | hi m1sc | 22:17 |
| jelmer | m1sc: the easiest thing to do is probably to create a trivial branch there, with one revision so that they get a DivergedBranches error | 22:17 |
| m1sc | jelmer: thx | 22:20 |
| spiv | jelmer: heh, hi :) | 22:23 |
| poolie | hi all | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!