| === elmo_ is now known as elmo | ||
| === bradm_ is now known as bradm | ||
| === Jordan_U_ is now known as Jordan_U | ||
| wgz | happy pre-morning all | 07:06 |
|---|---|---|
| fullermd | Oh no, not another one. | 07:07 |
| SamB | fullermd: they come once per day, dude | 07:10 |
| wgz | he can always hope, some day that may change. | 07:12 |
| fullermd | I've devoted my life to the erradication of this horrific scourge upon mankind. | 07:13 |
| ZyX-I | How can I get currently checked out revision (HEAD in git, . in mercurial, BASE in svn)? | 07:59 |
| === RenatoSilva is now known as Pikkachu | ||
| poolie | hi vila? | 09:52 |
| vila | poolie: hey ! | 09:53 |
| poolie | hey, thanks for your reply about orphans | 09:53 |
| vila | mypleasure | 09:53 |
| poolie | i was just going to ask the same question as bialix, about whether/why this isn't linked in to the main doc tree | 09:53 |
| vila | oops, didn't say hi :-} | 09:53 |
| poolie | also, whether your mail is a vote against changing the default | 09:53 |
| vila | surely not, my vote is (and always been) to turn it on :) | 09:54 |
| vila | it has been in my bazaar.conf since day one | 09:54 |
| poolie | ok | 09:55 |
| vila | and about linking to the main doc tree, yeah, it's on my radar to link all config option helps there but I haven | 09:55 |
| poolie | i have a branch | 09:55 |
| poolie | i was going to add some docs to the user guide too | 09:55 |
| vila | and about linking to the main doc tree, yeah, it's on my radar to link all config option helps there but I haven't looked at how this should be achieved | 09:55 |
| vila | there is a bug titled 'config doc is ugly' or something | 09:55 |
| vila | that I think about as a way to track that | 09:56 |
| vila | the most important part was to *have* a doc for each option which has been going pretty well since we started to migrate | 09:56 |
| poolie | yeah | 09:58 |
| poolie | fixing this together with deleting the ugly hardcoded doc would be good | 09:58 |
| ZyX-I | How can I get currently checked out revision (HEAD in git, . in mercurial, BASE in svn)? | 10:29 |
| LeoNerd | Define "get" ? | 10:40 |
| LeoNerd | You can know it, by bzr revno | 10:40 |
| LeoNerd | You can refer to it if needed explicitly by -1, because negative revnos count backwards from the top | 10:40 |
| ZyX-I | LeoNerd: It is answer to my question? | 10:44 |
| LeoNerd | Yes | 10:44 |
| ZyX-I | LeoNerd: Try the following: “bzr branch lp:bzr && pushd bzr && bzr update -r -2 && bzr log -r revno:-1”. I do see revision 6472 in the output | 10:45 |
| ZyX-I | But I must see 6471 here | 10:45 |
| LeoNerd | ? | 10:45 |
| LeoNerd | bzr log -r-1 | 10:45 |
| LeoNerd | Is sufficient | 10:45 |
| ZyX-I | LeoNerd: Exactly the same. | 10:45 |
| LeoNerd | Oh I see, you updated to -2 | 10:46 |
| ZyX-I | LeoNerd: It does not show currently checked out revision | 10:46 |
| LeoNerd | Yes it does. It shows the -checked out- revision | 10:46 |
| LeoNerd | Which is now earlier, because you up -r-2 'ed | 10:46 |
| ZyX-I | LeoNerd: I have checked out revision 6471 which is -2. “bzr log -r -1” shows 6472 | 10:47 |
| ZyX-I | LeoNerd: Maybe there is a problem with understanding term “checked out”. In mercurial terms it “currently checked out rev” = “working directory parent”. | 10:49 |
| ZyX-I | I am surprised there is no simple answer to such question. I bet I would have got “use HEAD/./BASE as revision argument” answers on git/mercurial/svn channels just after somebody saw my question. | 10:54 |
| fullermd | If you want the working tree rev, you want revno --tree (or various other incantations for revid) | 10:55 |
| LeoNerd | Ya, it's a rare situation | 10:57 |
| LeoNerd | 99.9% of the time the revno of the checkout == the revno of the branch | 10:57 |
| LeoNerd | Your update -r ... has specifically gone and changed that | 10:57 |
| ZyX-I | fullermd: Thanks. Thus “bzr log -r $(bzr revno --tree)” is the only way to get message for working directory parent? | 10:58 |
| fullermd | Probably. I have vague recollection of discussion about a tree: revspec, but I don't see it listed in the help, so it probably never got implemented. | 10:59 |
| LeoNerd | I don't understand this phrase "working directory parent" | 10:59 |
| LeoNerd | Working directory is a UNIX concept, the CWD of a process. | 10:59 |
| LeoNerd | The things important here are the checkout, and the branch. | 10:59 |
| fullermd | "working tree" would be the more common VCS-world term. | 11:00 |
| LeoNerd | Both have a (latest) revno concept. Normally the checkout is a copy of some revision of a branch, possibly including some local modifications that will become the next revision | 11:00 |
| LeoNerd | Normally, the checkout is a copy of the latest revision in the branch. So normally bzr revno and so on is unambiguous | 11:00 |
| LeoNerd | But specifically in your situation you rolled back the checkout to an earlier revision from the branch, so now you have two different "latest"s, depending whether you asked the branch (6472) or the checkout (6471) | 11:01 |
| ZyX-I | LeoNerd: “working directory parent” is how revision “.” is described in “hg help revisions”. | 11:03 |
| LeoNerd | Yah, please read what I just wrote :) | 11:03 |
| vila | right, that would be basis revision for the working tree in bzr speak | 11:04 |
| vila | ZyX-I: I think the initial confusion is that 'bzr log' always refers to the branch tip (which is almost always the same as the working tree (wt) basis revision) | 11:07 |
| vila | ZyX-I: instead of 'bzr update -r-2' you could have used 'bzr pull -r -2' and your wt will have pointed to the branch tip | 11:08 |
| vila | ZyX-I: but may be I don't understand what you were trying to achieve ? | 11:08 |
| ZyX-I | vila: No. Initial confusion is that all other VCS I have to support mention basis revision in either “vcs help revisions” (hg,git) or directly in the description of every command supporting revision arguments (svn). Only bzr requires use of the separate command. | 11:10 |
| vila | that doesn't tell me what you're trying to achieve :-/ | 11:10 |
| ZyX-I | vila: I want to make vim-addon-manager distinguish between cases “‘bzr pull’ has updated something” and “‘bzr pull’ did not touch working tree”. | 11:11 |
| vila | right, so better avoid 'bzr update' then, 'bzr pull' outputs 'No revision to pull' if nothing has changed IIRC | 11:12 |
| ZyX-I | vila: I don’t do “bzr update”. But the user may have done it. | 11:13 |
| ZyX-I | vila: If there are revisions to pull, but basis revision/=tip revision, “bzr pull” won’t update anything like other “vcs pull”, will it? | 11:14 |
| vila | hmm, I dunno for other VCSs but I think 'bzr pull' doesn't require a clean wt to pull, it merges the uncommitted changes if there are any instead | 11:16 |
| fullermd | Not relevant to the question ;p | 11:16 |
| vila | meh, the question, as I read it was: will pull do something if revisions are missing in the branch even if the wt basis revisions is not tip anymore | 11:17 |
| fullermd | No, bzr pull will force the tree up to the new head rev. That may or may not be a bug... | 11:17 |
| fullermd | In hg, pull will always pull the branch, and not touch the tree. You'd need a separate update, or a pull -u to get it to touch the tree too. | 11:18 |
| vila | ha right, I never ends up in setups where wt basis revision != branch tip | 11:18 |
| fullermd | That explains the years it took to land update -r... :p | 11:18 |
| vila | right, pull updating the wt if there is one matches my use cases... | 11:19 |
| vila | hehe | 11:19 |
| vila | probably, but I'm only one user, others have different workflows ;) | 11:19 |
| fullermd | I'm not entirely sure it should when it's not the previous tip. That seems like it may be slightly surprising. | 11:19 |
| vila | right, seems weird to me too, but I don't know the workflows involved hence my remark | 11:20 |
| vila | well, s/don't know/don't have enough practice with/ | 11:20 |
| fullermd | It's probably never come up or been explictly questioned at all. Just Happens(tm). | 11:21 |
| vila | I always thought that if you want to get a tree not based on your branch, it's only temporary (since you will commit on tip anyway) | 11:22 |
| vila | that bzr doesn't warn or block in these cases is probably a bug in itself | 11:22 |
| fullermd | I can't think of an obvious case where you'd want to pull, AND maintain that explicit older rev. Still, it feels more like the right choice. | 11:22 |
| fullermd | If I update -r, I'm telling bzr, I want the tree on that rev specifically; I'm not sure later saying 'pull' is best interpreted as "undo my update too". | 11:23 |
| * vila nods | 11:23 | |
| fullermd | You could make a case either way I guess. Just never been actually argued, TTBOMK, so we get the emergant behavior. | 11:23 |
| vila | add a --strict to pull ? | 11:24 |
| fullermd | Well, that also opens up the can of --overwrite worms. | 11:24 |
| vila | yeah, exactly | 11:24 |
| fullermd | Plus we'll get to tackle the bound branches arguments all over again. | 11:25 |
| vila | I can't hear you ? | 11:25 |
| fullermd | Would be fun, of course. But I don't really have the time for that... | 11:25 |
| jelmer | vila: could I perhaps trouble you with two reviews? | 11:54 |
| jelmer | https://code.launchpad.net/~jelmer/bzr/use-tree-iter-children/+merge/93609 and https://code.launchpad.net/~jelmer/bzr/iter-child-entries/+merge/93993 | 11:55 |
| vila | jelmer: I'm gently landing the eggs I'm juggling with and was about to lunch, will have a look after that | 12:01 |
| jelmer | vila: maybe you should have eggs for lunch ? :P | 12:02 |
| jelmer | vila: anyway, thanks :) | 12:02 |
| vila | hehe | 12:02 |
| === mrevell_ is now known as mrevell | ||
| vila | jelmer: reviewed | 14:22 |
| jelmer | vila: danke! | 14:25 |
| === mandel is now known as p | ||
| === p is now known as mandel | ||
| === kirkland` is now known as kirkland | ||
| === yofel_ is now known as yofel | ||
| pilot419 | I branched a working copy from remote, i want to create a experiment branch from checked out copy | 16:00 |
| mgz | go ahead and do that then :) | 16:01 |
| pilot419 | But bzr creating a seperate directory <experiment> | 16:01 |
| pilot419 | So i had to configure ide to experiment branch | 16:02 |
| mgz | seperate dirs are the default if you only want one tree to avoid confusing your ide, you can use switch, | 16:02 |
| mgz | either with the current beta and colocated branches, | 16:03 |
| mgz | or by reconfiguring your setup so you have a lightweight checkout and two different treeless branches | 16:04 |
| pilot419 | it's more difficult than Git :s | 16:05 |
| mgz | currently there's an extra step you need to begin with, yes | 16:07 |
| mgz | what version of bzr are you using currently? | 16:08 |
| pilot419 | 2.4 | 16:08 |
| pilot419 | So branching from remote will be normal bzr branch <remote> project | 16:11 |
| pilot419 | Next i need to create lite | 16:13 |
| mgz | okay, so you can either use the bzr-colo plugin, or do what I do | 16:14 |
| mgz | the first requires some specific forms to address branches, see the documentation | 16:14 |
| mgz | for the treeless branches thing, you do: `bzr init-repo --no-trees PROJECT` | 16:15 |
| mgz | then `bzr branch REMOTE PROJECT/trunk` (remote can be the local branch you already have, if you then change it's parent) | 16:16 |
| mgz | then `bzr checkout --lightweight PROJECT/trunk PROJECT/tree` | 16:16 |
| mgz | you can point your IDE at the tree folder | 16:16 |
| pilot419 | ok | 16:17 |
| mgz | and create a new feature branch from in there with `cd PROJECT/tree && bzr switch -b feature` | 16:17 |
| mgz | merging and other things that need branch references you just point at the branch locations you have in the filesystem | 16:17 |
| pilot419 | Ok maybe i got it | 16:23 |
| pilot419 | mgz: Thanks man | 16:26 |
| === mandel is now known as p | ||
| === p is now known as Guest68461 | ||
| === mgedmin_ is now known as mgedmin | ||
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| wilx | Hi. | 21:47 |
| wilx | What is the best way to convert whole SVN repo to BZR? | 21:47 |
| wilx | So far I was not able to arive to satisfactory result. | 21:47 |
| bob2 | what happened when you tried bzr-svn? | 21:47 |
| wilx | The best so far seems conversion based on svn2git -> fasexport from GIT -> fastimport to BZR. | 21:48 |
| bob2 | note that oddly managed svn repos will suck to import into anything else | 21:48 |
| wilx | bob2: It seems to convert only a single branch at once. | 21:48 |
| mgedmin | there's also svn-all-fast-export | 21:48 |
| wilx | mgedmin: Where is that? | 21:48 |
| mgedmin | apt-get install svn-all-fast-export, or http://repo.or.cz/w/svn-all-fast-export.git | 21:49 |
| mgedmin | I just learned about it the other day | 21:49 |
| mgedmin | seems to be very fast | 21:49 |
| mgedmin | and you can define rules to straighten out quirks in a messy svn history | 21:50 |
| wilx | http://gitorious.org/svn2git/ | 21:52 |
| wilx | That seems like a older version of svn2git. | 21:52 |
| wilx | I have a fastexport file that it created. It contains branch "1.1" but bzr fastimport never creates this one branch. It also ignores many of the merges. | 21:53 |
| mgedmin | what about https://github.com/nirvdrum/svn2git ? | 21:53 |
| mgedmin | I'm confused -- are there two different tools both called svn2git? | 21:53 |
| wilx | mgedmin: It looks more like forks of the same source. | 21:54 |
| mgedmin | I recently watched a linuxconf.au video about svn -> git conversion tools | 21:54 |
| mgedmin | the guy mentioned three existing ones, described their downsides (two couldn't handle messy conversions, the last one was too slow, iirc) and told how they wrote a fourth tool based on those | 21:55 |
| mgedmin | unfortunately I don't remember any of the tool names | 21:55 |
| mgedmin | I wonder if svn-all-fast-export is that fourth tool | 21:55 |
| mgedmin | btw, re: "It seems to convert only a single branch at once." | 21:56 |
| mgedmin | bzr svn-import should be able to handle multiple branches | 21:56 |
| mgedmin | afaiu | 21:56 |
| wilx | http://barrbrain.github.com/svn-dump-fast-export/ | 21:58 |
| wilx | This is the one from the video, I think. | 21:58 |
| wilx | I believe it did not work well either. Let me retest. | 21:58 |
| jelmer | wilx: 'bzr svn-import' will indeed import all branches from the repository | 22:05 |
| wilx | Ah, right, it crashed, the http://barrbrain.github.com/svn-dump-fast-export/ tool. | 22:06 |
| jelmer | fast-import isn't a great format for conversion that doesn't involve git, as it can only represent things that exist in git | 22:16 |
| wilx | Ah, I know why I did not like svn-import. It seems that it entirely ignores all merges. | 22:21 |
| wilx | Hmm... | 22:21 |
| wilx | But cherry pickings are not recored in bzr specially, right? | 22:21 |
| wilx | That might be it. | 22:21 |
| jelmer | wilx: yeah, they're indeed not recorded (yet). None of the DVCSes track cherry pick merges in their metadata yet. | 22:22 |
| mgedmin | I think arch used to :) | 22:23 |
| mgedmin | is it not a DVCS now? | 22:23 |
| wilx | Arch/TLA was weird. | 22:24 |
| fullermd | Darcs does too. | 22:24 |
| wilx | jelmer: Well, The SVN->GIT conversion did show some merges though. | 22:24 |
| fullermd | Probably need a 'conventional' in that sentence 8-} | 22:24 |
| jelmer | mgedmin: ah, sorry, yes - arch did indeed | 22:28 |
| mgedmin | don't mind me, I'm just trolling | 22:28 |
| mgedmin | when people say "DVCS" nowadays, they mean git + hg + bzr | 22:29 |
| fullermd | Actually, I'm pretty sure they mean "git". | 22:30 |
| fullermd | (see, _that's_ trolling!) | 22:31 |
| spiv | fullermd: really, I thought they meant "monotone or darcs" ;) | 22:43 |
| fullermd | Don't be such a fossil. | 22:43 |
| mgedmin | svk gets no love for some reason ;) | 22:43 |
| wilx | SVK seems like SVN with disconnected operations. | 22:59 |
| wilx | Not too distributed. | 22:59 |
| wilx | Though I have never used it seriously. | 22:59 |
| mwhudson | mgedmin: i have no idea why!! | 23:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!