[00:46] I have a dev branch and a trunk branch [00:46] for some reason I did bzr pull ../trunk [00:46] to the dev [00:46] and now I'm on my trunk in the dev [00:46] since it was checkout, the remote is just teh same [00:46] how can I revert back [00:47] i believe pull just pulls the revisions and sets the head, you might be able to set the head [00:47] maybe 'bzr heads'? [00:47] ? [00:47] but there used to be 889 revisions to dev [00:47] now it's the 539 from the trunk [00:47] I'm lost [00:47] haha [00:48] most of the stuff in dev were merged in trunk thank god for that [00:48] throw it away and reclone [00:48] they are in the repository most likel;y [00:48] bob2: but the remote is also 539 now [00:48] so ypu pushed it? [00:48] or did you unfortunately use a bound branch [00:48] no but it was checked out [00:48] or something [00:48] yeh [00:48] bound branch [00:48] sadness [00:49] so there's nothing to do? [00:49] it just gets replaced like that in an instant [00:49] seems pretty crazy to me [00:49] there has to be a way to set the head [00:49] took like half a second [00:49] since all the revisions are there [00:49] here is the dev: http://bzr.savannah.gnu.org/lh/librejs/dev/changes [00:49] did you try bzr heads and see [00:49] if it listed the dev one? [00:50] here is the trunk: http://bzr.savannah.gnu.org/lh/librejs/trunk/changes [00:50] bzr heads doesn't seem to exist [00:50] unknown command heads [00:50] it's easy [00:50] it says [00:50] says its in the bzrtools plugin for me [00:50] repush the correct branch [00:50] and heads is a plugin [00:50] bob2: but I don't have the correct branch anymore [00:50] get it then [00:50] where? [00:50] do you not know the old revision id? [00:51] 889 I think [00:51] the full revision id [00:51] the one you get from testament i think [00:51] from testament? [00:51] I don't get it [00:51] revision-id: markgrandi@gmail.com-20120602005836-b3b0uowcgjql8epb [00:51] like that [00:52] I use bzr but not in an advanced way [00:52] how can I tell the revision id like that? [00:52] it's definitely possible to recover [00:52] maybe ask on the mailing list [00:52] look in bzr.log [00:52] ps bound branches are bad mmmkay [00:52] haha [00:52] when you commit [00:52] well i'm learning that now [00:52] it will tell you the revision id [00:52] so look for when you commited revision 889 or whatever [00:52] because it's pretty easy to do a pull ../trunk instead of merge ../trunk [00:53] but that commit is gone [00:53] since it's the other branch now [00:53] dev is trunk [00:53] no? [00:53] its still in teh repositiory [00:53] so you can recover it. [00:54] oh yeh [00:54] so search the log file for 889 or whatever it was [00:54] ok [00:55] and bound branches arn't that bad, although it does seem silly that a pull will automatically push to the remote branch [00:55] if you look at the branch changes: http://bzr.savannah.gnu.org/lh/librejs/dev/changes/541?start_revid=541 [00:55] it's only those for trunk [00:55] that are now in dev [00:55] just search for the 889 string in bzr log [00:56] see if you can get the revision-id [00:56] ok [00:56] like that right: bzr log | grep "889" [00:56] I can't see anything [00:57] try 'commited' [00:57] did you commit the last revision on this computer? [00:57] i don't think so [00:58] ah well, I'll just give up I guess [00:58] haha [00:58] It's not the endo f the world, but it does suck [00:58] what if you are in charge of a huge project :-) [00:58] and that happens [00:58] you can get it back [00:58] the data is still there =P [00:58] just gotta find that number [00:58] or ask on the mailing list, maybe there is an easier way [00:58] it's still even in the remote repo? [00:59] yeah. [00:59] i think this would happen in git / hg / whatever too =P [01:00] hehe [01:00] ok i'm writing to the mailing list [01:01] If pull didn't require --overwrite, then trunk _did_ have everything dev did. [01:03] yeah. you just have to reset what is the 'head' revision [01:04] Right, I'm pointing at " most of the stuff in dev were merged in trunk thank god for that" [01:04] It wasn't most, it was all, else the pull wouldn't have Just Worked. [01:04] fullermd: really? [01:04] it would have choked on it? [01:05] bzr: ERROR: These branches have diverged. Use the missing command to see how. [01:05] Unless you did a --overwrite or something, pull won't run if the remote isn't a superset of the local. [01:06] Or less stiltedly, if the pull will mean your local branch no longer has something it had before. [01:07] ah ok [01:07] so that's one good news [01:07] I still posted that email on the mailing anyway [01:07] just curious :-) [01:07] but thanks it really makes me feel better now [01:07] 541 seems less "important" than 889 though [01:08] I thought I'd get to a 1000 commits all by myself and throw a party [01:08] :-P [01:08] heh [01:08] Oh, but it's more fun this way. It means you can get to a thousand commits MULTIPLE times! [01:09] haha [01:09] The real trick is spacing them out enough that you're in good enough shape for each party... [01:09] it's funny how revision numbers really mean nothing in bzr [01:09] they do [01:09] just in the context of the branch [01:09] well they do but only in a branch [01:09] yeh [01:10] if you do a qlog then you see that all the merged ones are like 400.1 - 400.100 etc [01:10] it's a completely different take than git [01:10] i like the revision numbers though, easier to remember [01:10] that SHA1 hashes [01:10] :-P [01:10] its the same idea, kts just that bzr gives you numbers, yeah [01:10] sha1 are the most unmemorable things ever [01:10] It does have its downsides. It means when you compose a clever little jingle from the revno in the commit message, years later nobody will get the joke :| [01:10] hehe [01:11] also I have to stop running rm -rf dev/ [01:11] everytime there's a problem maybe :-) [01:11] better to do mv dev dev-bck [01:11] haha [01:11] Well, doing it once or twice in / will cure you of that... [01:11] hha [01:12] everytime there's a problem I tend to run rm never think to run mv [01:12] Funnily enough, I needed to make a new FS for working on something last week. [01:12] Needed a name. Well, it was just for development, so I can just call it /dev! [01:12] Hey, wait, why is bzr suddenly blowing up when I try to run it? [01:13] Hm, everything else is too. What the he... oh, no... [01:13] hehe [01:14] that reminds me I should make backups of my ssh and gpg keys [01:14] haha [01:14] Anyway, back a little less off-topic. Probably, the last thing on the dev branch was part of a recent merge to trunk, so if you look back through log (paying especial attention the merges), you may be able to spot it that way to restore if you want to. [01:15] hmm [01:15] so when you make a merge [01:15] yeah, thats what i suggested, i think lduros did it on another computer so [01:15] all of those revisions are kept [01:15] those revisions from the other branch? they're not merge into one revisions in the new branch [01:16] i guess i can't wrap my head around how things work [01:16] yeh I do a lot of my gnu development during my work lunch break [01:16] so some is probably at work [01:17] I guess I'll keep working on trunk for the night [01:18] they are kept in the repo, it doesn't delete any revision [01:18] just creates new ones [01:19] Merge makes a new rev to connect the merged revs in, but they're all still there individually. [01:19] ah [01:48] Fixed! :-) [01:49] I guess that's what you all were talking about: https://lists.ubuntu.com/archives/bazaar/2012q2/074860.html [01:50] the reason I couldn't find revno 889 [01:50] is because it was 886 [01:50] haha [01:50] Well, we can hardly be held responsible for you running around with your monitor upside-down :p [01:52] heh [01:58] ps unbind [02:09] bob2: yes, definitely [11:27] hi. [11:28] I have revisions 121, 122, 123 the last revisions. [11:28] I want to remove changes introduced by 122 [11:28] how do I do this ? [11:28] bzr revert -r-3..-2 ? [11:29] or bzr merge . -r-3..-2 ? === yofel_ is now known as yofel === zyga is now known as zyga-food [12:14] why do I get : bzr dh-make hello-2.7 hello-2.7.tar.gz bzr: ERROR: command 'dh-make' requires argument TARBALL [12:14] bzr help dh-make [12:17] than ks [12:17] but how does that help? [12:18] because then you'll know how to use it [12:20] I use the right syntax, don't I? [12:22] bob2: I didn't understand [12:22] ok [12:22] good luck [12:22] ? [12:32] anyone else? [12:33] matanya: I've not used it, but looking at http://doc.bazaar.canonical.com/plugins/en/builddeb-plugin.html#dh-make it appears you're missing a VERSION string. [12:33] 2.7 [12:34] so the name of your tar ball is used as version string instead. [12:34] you've only got two strings as argument for dh-make [12:34] 1) hello-2.7 2) hello-2.7.tar.gz [12:34] so bzr dh-make hello 2.7 hello-2.7.tar.gz [12:34] #2 should have been #3 [12:34] guess that would be more right [12:35] bzr: ERROR: Either run the command from an existing branch of upstream, or move hello-2.7 aside and a new branch will be created there. [12:35] ok. rm hello-2.7 worked [12:35] thanks [12:36] you're welcome. good luck. [13:10] hey [13:11] I've got a question ! I use colo-switch to move between branch. The problem is that if I'm working on a new Python module, I always got a conflict because bzr does not remove *.pyc, *.pyo files from the new module's dir. So I got a "unable to remove directory : not empty" when switching back to my old branch. [13:11] That's just really annoying, how can I fix that ? === zyga-food is now known as zyga [13:21] Merwin_: to resolve that conflict, just delete the directory and vestigal pyc files then do `bzr resolve dir` [13:22] to avoid it in future there's a config setting that will move stuff like that to a seperate directory rather than causing conflicts [13:26] which I'm failing to find the name of, vila will know. [13:26] bzr.transform.orphan_policy=move [13:27] in either bazaar.conf or your branch.conf [13:39] * vila thinks we should 1) rename it to something more sensible, 2) turn it on by default [13:40] I think we'll get less reports for people searching for their orphans than we get for the spurious conflicts [13:50] Hi all :-) [13:50] I'm wondering about checkouts (bound branches) and how a commit works there. [13:51] I know that the revision is half-committed locally, then pushed, then fully committed locally if the push succeeds and rolled back otherwise. [13:52] But my question is: could that push be turned into a dpush if, for instance, the remote branch were stored in a git repository? [13:52] This way we could keep a normal workflow of simply committing and not worrying :-) === Quintasan_ is now known as Quintasan [14:45] wgz, vila bzr resolve --action=take-other should work fine ? [14:45] Yeah but anyway, I'll still have the conflict :x [14:45] I'll try the bzr.transform.orphan_policy [14:46] Merwin_: yeah, the idea it to *avoid* the conflict [14:46] yep :D [15:44] vila: Is there any way to use a colocated branch's name in a config, the way I can use appendpath to add a branch's location? [15:46] abentley: I'm not sure I understand what you call a colocated branch's name [15:46] appendpath was only usable in locations.conf [15:47] vila: the part that comes after the = in "file:///foo/bar,branch=name" [15:48] vila: I would be fine with a solution that was only usable in locations.conf. [15:50] abentley: there are 'relpath' and 'basename' that replace what appendpath was providing but it's still unclear to me on how you would specify a section for a colocated branch (or if it will work) [15:51] vila: I don't want to specify a section for the colocated branch, just the container. e.g. "[/foo/bar]" for the previous example. [15:52] vila: Say I have project bar, and I'm using colocated branches, and I want to push them to Launchpad without having to specify the push location. [15:54] abentley: each colocated branch into its own launchpad branch ? [15:54] vila: Yes. [15:54] well, I don't think push supports that :-/ [15:55] and I never looked at how config behaves for colocated branches to be honest [15:56] does launchpad authorizes the additionnal paths used for colo branches ? [15:57] vila: Sure push supports that. It's not a colocated branch on Launchpad, just a regular branch. [15:57] vila: I'm doing it manually all the time. [15:57] That's not what I meant by supporting the additional paths used by colo branches :) [15:58] vila: I doubt launchpad authorizes the additional paths used by colo branches. Since launchpad wouldn't recongnize colo branches if it did, that's for the best. === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno === zyga is now known as zyga-afk === alorente1 is now known as alorente [17:52] I created a local branch and commited my code, how can I push it to remote branch ? [18:11] I created a local branch and commited my code, how can I push it to remote branch ? === Noldorin_ is now known as Noldorin