| delinquentme | jelmer, know of a way to branch off of a particular revno of a bzr repo? | 00:05 |
|---|---|---|
| spiv | delinquentme: "bzr branch -r REVNO" | 00:06 |
| jelmer | delinquentme: bzr branch -rX | 00:07 |
| delinquentme | lol am i supposed to get nothing returned when I run a bzr status for a newly branched dir? | 00:30 |
| bob2 | what do you think it should show? | 00:34 |
| bob2 | you have no local changes | 00:34 |
| delinquentme | should it not say that ? | 00:35 |
| bob2 | no | 00:35 |
| delinquentme | sounds like a quiet fail | 00:35 |
| delinquentme | it should :D | 00:35 |
| bob2 | it's not a quiet fail, it had nothing to say, so said nothing and exited with 0 | 00:35 |
| jelmer | I think it says "X revisions branched." usually? | 00:35 |
| bob2 | bzr branch does, delinquentme is talking about 'bzr status' in the branched dir | 00:36 |
| jelmer | bob2: ah, whoops - sorry | 00:36 |
| mgz | morning! | 08:01 |
| fullermd | ETOOPERKY | 08:02 |
| vila | hi there | 08:35 |
| fullermd | Where?? | 08:36 |
| mgz | behind you! | 08:38 |
| fullermd | Oh, good. I could use a good backrub. | 08:41 |
| * vila rubs | 09:09 | |
| === AfC1 is now known as AfC | ||
| fullermd | bzr ping -> Headers: {'Software version': '2.0.3'} | 14:39 |
| fullermd | Furrfu :| | 14:40 |
| mgz | heh, against which server fullermd? | 14:42 |
| fullermd | Sourceforge | 14:42 |
| fullermd | But hey, their docs claim they support bzr 1.10, so in relative terms... | 14:43 |
| crazydip | having commited rev 1, 2, 3, 4, 5 how do i "undo" the changes done in 2 and 4 without "undoing" (reverting, uncommiting) the changes in 3 and 5? | 14:50 |
| fullermd | A better phrasing for what you want to do is "reverse" the changes; you can't undo them per se, since they're part of history. | 14:51 |
| fullermd | Basically the [im]mortal equivalent of something like "bzr diff -c2 | patch -R". | 14:52 |
| fullermd | You can use merge to do a lot of the work. e.g., "bzr merge -r 2..1 ." (note the reversed numbers, and don't miss the trailing '.' there) | 14:52 |
| fullermd | That'll stage up a "reverse" of rev 2, which you can then check and fix any conflicts and test and commit. | 14:53 |
| fullermd | Then you can do the same for rev 4. | 14:53 |
| crazydip | does the trailing . in "merge -r 2..1 ." mean "all files" in -r 2..1? | 14:54 |
| fullermd | Not exactly. It tells merge what branch to 'merge' from. In this case, the branch you're sitting in. | 14:55 |
| crazydip | ok :) | 14:55 |
| crazydip | and can I merge both 2..1 and 4..3 before commiting? Like with "merge -r 4..3 . --force"? | 14:57 |
| fullermd | You could. My impulse would be not to, just for cleanliness. | 14:57 |
| crazydip | that's some great and clear advice! thank you fullermd! | 14:59 |
| fullermd | That's 'cuz I'm clearly great 8-} | 15:01 |
| crazydip | I did not want to say anything and look too much like a newb, cause it was so obvious :D | 15:02 |
| fullermd | Oh, don't worry, we never point and laugh at anybody on this channel. | 15:05 |
| fullermd | We've got a whole separate channel for that. | 15:05 |
| crazydip | #bzr-lolz? :) | 15:05 |
| fullermd | That's too easy to confuse with #bzr-lolcats, where we concentrate on things like "I can has merge proposal?" and "I made you a patch, but I uncomitted it" | 15:09 |
| danielbrauer | fullermd: I've often seen talk between svn folks wishing there was an "svn obliterate", which would roll back the repository, removing revisions entirely. It still doesn't exist in svn, but is there something like that in bazaar? Or does it make even less sense for dvcs in general? | 15:51 |
| fullermd | It's not conceptually impossible, but there are a number of practical difficulties, and I'm not aware that anybody's actually implemented it in a particularly clean way. | 15:52 |
| fullermd | The usual fallback involves creating a new history without the thing you want to obliterate, and flag-day'ing everybody over to it. | 15:53 |
| danielbrauer | I could see it being difficult to resolve if you've got a lot of branches. | 15:53 |
| fullermd | Just so. The CVCSen have a somewhat easier time of it, since clones of the 'main' repo are in practice read-only, so there's only one place to have to remake the world. | 15:55 |
| fullermd | Still, easier is a long way from "easy". | 15:55 |
| fullermd | It was "easy" in CVS. Since the repository had no awareness or meaning to corruption, you're free to corrupt the crap out of it, and everything keeps working as well as it used to ;p | 15:55 |
| danielbrauer | I'm super-new to bazaar, and have a repository going but I've only read the first few pages of the manual. I feel like I have a poor grasp on the relationship between different branches. Is it the case that all working copies and repositories are equal, except that they have a hierarchy in terms of where they were branched from? | 15:58 |
| crazydip | i'm so glad we have dvcs's and can just ignore aweful cvs :) | 15:58 |
| fullermd | No, a set of branches can have any arbitrary relationship to each other. Alternately, they have _no_ necessary relationship to each other. | 15:59 |
| fullermd | In a technical sense, any two branches are related based on what revisions they do/don't share. | 15:59 |
| fullermd | Of course, _socially_ speaking, in any project you probably have something rather like a hierachy. | 16:00 |
| fullermd | But that's a matter of your convention and human/social necessity, not tool technical necessity. | 16:00 |
| danielbrauer | Ok. So every branch is a full-fledged repository with a full history, and it will share history with another repository from before the branch happened. | 16:00 |
| fullermd | You might find some of http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs useful, particularly starting with http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief | 16:01 |
| danielbrauer | Ok, that probably answers my next questions, which were about the relationship between all the different commands that appear to do similar things. I'll be back when I've read these pieces. Thanks! | 16:03 |
| crazydip | danielbrauer: in short, forget about all the restrictions of cvs - each branch is a clone of whatever you branched from... you can do whatever you want with it, make changes, commit changes, revert changes and if you choose, another person can merge those changes to their branch or you can merge someone else's stuff into your branch --- like fullermd said, the restrictions come on a social level, not technical | 16:12 |
| danielbrauer | Right. I sort of get that, but it confuses me when I see checkout as well as branch, and merge as well as commit, whereas those two pairs each seem to accomplish the same sort of thing. | 16:14 |
| danielbrauer | Is the difference a matter of "binding"? | 16:15 |
| crazydip | danielbrauer: i know this is about bzr but to tell you the truth, what best helped me understand how dvcs' work is Linus' presentation on git at Google from a few years back - it's all relevent to bzr (just search "linus git" on youtube) | 16:15 |
| danielbrauer | Will do, thanks | 16:15 |
| fullermd | Plz to ignore binding. It'll only confuse things way more. | 16:15 |
| danielbrauer | Ok, I'll do that too. (: | 16:16 |
| fullermd | checkout/branch and merge/commit are definitely not at all the same thing. | 16:16 |
| danielbrauer | No, I assumed not. It's just that so far I've only read explanations that involve similar-looking arrows. | 16:17 |
| fullermd | I'd start with trying to internalize the beginning of that PiecesInBrief. If you think of everything in terms of Revisions, things get a bit clearer. | 16:17 |
| danielbrauer | Yeah, the inherent unrelatedness of revisions is something I hadn't gathered before. | 16:17 |
| fullermd | Commit is a way (almost the only way, ignoring exotic situations, which you should) that Revisions get created. | 16:17 |
| fullermd | Everything else is just a matter of how they get shared around after being created. | 16:18 |
| fullermd | Oh, Revisions are very strongly related. They're just the _only_ thing that relates. | 16:19 |
| fullermd | Branches are nothing but collections of Revisions, and two Branches that have the same collection are for most purposes interchangeable and indistinguishable. | 16:19 |
| fullermd | (I'm rather othersimplifying for the purposes of this discussion, so don't try to push it too far, but from where you're sitting, it's near enough to true) | 16:20 |
| fullermd | (sorry, I just used up my daily allotment of commas...) | 16:20 |
| danielbrauer | No problem. I appreciate the time. | 16:21 |
| fullermd | If you have a background with any VCS, you probably understand enough about the inspection-type commands like diff and status and log, that we can ignore them. | 16:22 |
| fullermd | So it's only the action-type ones you should worry about right now. | 16:22 |
| danielbrauer | Yeah, I've used svn for a long time and while it still manages to confound me every now and then, I do understand what all the commands are supposed to do in most cases. | 16:22 |
| danielbrauer | I think the thing that confused me until now is that you can have a repository, branch, and working tree all in the same place. | 16:23 |
| danielbrauer | That's not obvious from the beginning of the manual. | 16:23 |
| fullermd | We can make a quick 2-category division there, between the commands that _make_ new revisions (only 'commit'), and the ones that move revisions around amongst branches (push, pull, merge) | 16:23 |
| danielbrauer | Ok. | 16:23 |
| fullermd | push and pull can be thought of as symmetric; one makes THAT branch equivalent to THIS one, and the other makes THIS branch equivalent to THAT one. | 16:24 |
| fullermd | (or refuses to do so, if that would lose history) | 16:24 |
| danielbrauer | Ok. Presumably the branches have to be related in some way for that to work? | 16:24 |
| fullermd | Yes. Colloquially speaking, the "target" branch (THAT or THIS, depending on whether you're push'ing or pull'ing) has to be an "older" version of the source. | 16:25 |
| fullermd | Or alternately phrased, only one side can have changes the other doesn't. | 16:25 |
| danielbrauer | Got it. | 16:25 |
| fullermd | If both have changes the other doesn't (they've diverged), you need to use merge to pull them together. | 16:25 |
| danielbrauer | What's the difference between update and pull? | 16:26 |
| fullermd | And merge doesn't _quite_ bring them together, it just prepares them to bring together; you need to use 'commit' afterward to make a new revision, which does the entogetherication. | 16:26 |
| fullermd | (it's totally a word. Look it up. As soon as I hack the OED.) | 16:26 |
| fullermd | Let's ignore update for right now; that'll just confuse things a bit. | 16:27 |
| danielbrauer | Ok, that's similar to svn's merge. The result is a bunch of modifications to your working copy. | 16:27 |
| fullermd | I believe so, yes. It leaves you with a stack of changes to check over, and then commit. | 16:27 |
| danielbrauer | But I guess merge preserves more history in Bazaar? | 16:27 |
| fullermd | Yes. The history models are somewhat different. | 16:28 |
| jml | https://code.launchpad.net/~jml/bzr/rubberstamp/+merge/130850 | 16:28 |
| fullermd | In svn, history is basically linear (and then there's some extra metadata that gets written about merges, off to the side) | 16:28 |
| danielbrauer | Right. | 16:29 |
| fullermd | Whereas in bzr (and most other major DVCSen), history is a DAG. | 16:29 |
| fullermd | And if that meant something to you, we get to shortcut a lot of explanation. | 16:29 |
| danielbrauer | Yup. | 16:29 |
| danielbrauer | Yeah, I | 16:30 |
| danielbrauer | 'm a CS graduate. They only taught us CVS but I do know some theory. (: | 16:30 |
| fullermd | Eggselent. | 16:30 |
| fullermd | So every revision is a vertex in the graph of history. | 16:30 |
| fullermd | And it's got some number of edges sprouting out of it pointing at other revisions, which are its parents. | 16:31 |
| fullermd | It may have 0, which means it's an initial revision you created from nothing (e.g., after a 'bzr init') | 16:31 |
| danielbrauer | Ok. Now should I be thinking about "history" as a single branch, or all related branches from a repository? | 16:31 |
| fullermd | It may have 1, which means it's a "normal" rev, like you have in svn. You started from some existing rev, made a change, and committed it. | 16:31 |
| fullermd | Mmm. Both, in a way. | 16:32 |
| fullermd | Or, it may have 2 (or more, though that's rare and usually pointless) "parents", which means it's a merge. That's how most DVCSen model it; merges are some extra metadata, it's just a rev with 2 parents instead of 1. | 16:32 |
| fullermd | So in high concept, a _branch_ is really just a pointed to some node, saying "That's where I am", and the history of the branch is gotten by walking back along the edges. | 16:33 |
| fullermd | (pointer) | 16:33 |
| danielbrauer | That makes sense. | 16:34 |
| fullermd | So, with a CS background from that, you can see how relationships between Branches come about; you look at the DAG of each, and find the common subgraphs. | 16:34 |
| fullermd | If they both have the same head, they're identical and functionally interchangeable. | 16:34 |
| fullermd | If the head of A is in the history of B, then B is a "later" version of A. You can "cd B ; bzr push A" or "cd A ; bzr pull B", to sync them up. | 16:35 |
| fullermd | If the head of neither is in the other, there's some divergeance. You can walk back the history and find the common node, and now we know where they diverged from each other. | 16:36 |
| fullermd | (or there may be no common node, all the way back; then we know one branch is gcc, and the other is mozilla, say) | 16:36 |
| danielbrauer | Ok. And for any branches that share history, the history will all be shared before a certain point? That is, from the most recent revision they share, they will share all revisions previous to that one? | 16:37 |
| fullermd | (or >1 unconnected common nodes, which... well, we'll ignore that) | 16:37 |
| fullermd | Right. Revisions have a purportedly universally unique identification, so a given rev is always the same everywhere. And since part of that identity is the parent list, everything earlier is known identical. | 16:37 |
| danielbrauer | Got it. | 16:38 |
| fullermd | So what "merge" does is stage you up for a commit with 2 parents, which connects the two separated branches/histories into a new branch that contains both. | 16:38 |
| danielbrauer | Ok. In Subversion, I find we do a lot of cherry-picking changes when merging. Instead of taking everything from a branch that isn't in common with trunk, we just take a few revisions here and there. That sounds different from DVCS, because it would mean that two branches shared a revision but not all of its history. | 16:40 |
| fullermd | Right. Which is impossible, by the data model. | 16:40 |
| fullermd | So cherrypicks are unrecorded; the tool can't tell after the fact that it wasn't just a manual change. | 16:40 |
| fullermd | (except in systems like darcs, which are fundamentally different) | 16:41 |
| danielbrauer | Ok. So although revisions necessarily record a set of changes and allow you to trace the history that led to the revision, they can't be moved around as arbitrarily as svn's revisions, which are more "change sets". | 16:42 |
| fullermd | Not exactly right on the svn side, but right on the limitations of the DVCSen. | 16:42 |
| danielbrauer | Ok. That's fine because I decided a while ago that I don't need to understand svn fully in order to use it properly. | 16:43 |
| fullermd | Each rev is conceptually "the whole history up to this point", so you can't move them around in the graph after they're created. | 16:43 |
| fullermd | (so when we talk about about "moving revs around" with push/pull/etc, what we really mean is just changing which subgraph a branch refers to; can't change how the graph is shaped) | 16:44 |
| fullermd | In a sense, there's One Giant Universal DAG out there, with some large number of head nodes, which isn't remotely entirely connected, that contains the world of every software project. | 16:45 |
| fullermd | If you just handwave away the minor implementation issue of getting the contents of a rev once you've named it (and that's just the sort of detail academics are supposed to ignore), you can shortcut all that silly development effort and create software from thin air just by naming the right revision ;) | 16:47 |
| danielbrauer | Ok. So I could set out to merge Mozilla and gcc? | 16:49 |
| fullermd | It's perfectly possible. | 16:49 |
| fullermd | The result might be silly, but it's possible :) | 16:49 |
| danielbrauer | I'll get started right away. | 16:49 |
| fullermd | You'd wind up with a branch (one head node) that, if you follow back, terminates in (at least) two separate nodes with no parents. | 16:50 |
| fullermd | Which is a perfectly valid graph. | 16:50 |
| danielbrauer | Understood. | 16:50 |
| fullermd | Actually, a large number of the branches I work with every day have at least 2, sometimes 3 or 4 or more "initial" revisions. | 16:50 |
| danielbrauer | What are some examples? | 16:51 |
| fullermd | Think of the process "import a vendor branch"; that's what you're doing in that case. | 16:51 |
| danielbrauer | Oh, right. | 16:51 |
| danielbrauer | So kind of like an external, but you're actually folding it into your branch? | 16:51 |
| fullermd | So I've got an existing libthis and libthat that I want to use in projectfoo; I just merge those (independent, unrelated) branches, and boom; I've got a branch with 3 initial revs. | 16:52 |
| danielbrauer | And then you could merge future revisions of those libs into your branch later if that's what you want. | 16:52 |
| fullermd | Roughly, yeah. You can think of an external as "include by reference", whereas merging it in is "include by value". | 16:52 |
| danielbrauer | Right. | 16:52 |
| fullermd | Right. Especially useful if I don't actually want libthis, but rather libthis-plus-some-local-changes. | 16:52 |
| alkisg | Hi, here's a "view" URL where I can see a specific file from my branch: http://bazaar.launchpad.net/~ts.sch.gr/sch-scripts/trunk/view/head:/debian/sch-scripts.gconf-defaults | 16:53 |
| alkisg | I'd like to find the equivalent "download" URL, to use in some script for some weird reason that doesn't really matter. Is that possible, or the download links are dynamically generated + temporary? | 16:53 |
| fullermd | The local changes just happen in my branch, and the pristine libthis's merge cleanly (I hope) | 16:53 |
| danielbrauer | Surprise API rewrite! | 16:53 |
| fullermd | "API" is the sound you make when it changes out from under you. | 16:54 |
| fullermd | alkisg: I'm not sure. That's a launchpad/loggerhead question... I'm not sure there is one, but I'm no authority on the matter. | 16:55 |
| alkisg | fullermd: thanks, I first asked in #launchpad but I was instructed to ask here... I'll wait for a bit in case some loggerhead guru answers :) | 16:55 |
| === beuno is now known as beuno-lunch | ||
| danielbrauer | Ok, lunch now. Thanks for the explanations. It's really helped, along with the Fuller ones. | 17:03 |
| JPeterson | whats the link to the raw file in a launchpad repo? for example http://bazaar.launchpad.net/~kovid/calibre/trunk/download/head:/src/calibre/libwand.py doesn't return a valid file. | 17:19 |
| JPeterson | it returns "The resource could not be found. " | 17:19 |
| JPeterson | searching for "launchpad wget repo file" doesnt return an answer unfortunately. sadly and answer would be valuable to me. | 17:21 |
| mgz | JPeterson: `bzr cat -d lp:calibre src/calibre/libwand.py` | 17:23 |
| mgz | unless you're also trying to build an iso and don't have anything installed... | 17:23 |
| JPeterson | thx. what if i have curl but not bzr? | 17:24 |
| mgz | disappointingly inefficient still, and ick, that's some ugly ctypes | 17:25 |
| mgz | JPeterson: `curl https://launchpad.net/bzr/2.5/2.5.1/+download/bzr-2.5.1.tar.gz` | 17:28 |
| JPeterson | what if dont have write access? | 17:29 |
| mgz | but pipe that to something... | 17:29 |
| * fullermd waits 'till we get to the "fire up the virtual machine you just mounted over an ssh tunnel" stage... | 17:29 | |
| mgz | it's thought-experiment day apparently | 17:30 |
| fullermd | I think these are more thoughtless-experiments. | 17:31 |
| mgz | "what's the least convenient way of getting a file from launchpad in order to put it in an iso" | 17:31 |
| fullermd | "Look, python's not that complex a language, and you've got those toggle switches just sitting there anyway..." | 17:31 |
| mgz | JPeterson: what are you actually doing, out of curiosity? | 17:34 |
| JPeterson | reading a launchpad repo file | 17:34 |
| mgz | JPeterson: on the grand scale | 17:35 |
| mgz | when you have completed all the little steps that include reading this file, what will you have done? | 17:35 |
| JPeterson | same thing as bzr cat | 17:35 |
| JPeterson | the html interface show that "http://bazaar.launchpad.net/~kovid/calibre/trunk/download/head:/645%40b0dd1a5d-880a-0410-ada5-a57097536bc1:libprs500%252Ftrunk:src%252Flibprs500%252Flibwand.py/libwand.py" is a valid url | 17:38 |
| JPeterson | but i would like a shorter url than that | 17:38 |
| JPeterson | one that only include the path. not revision. | 17:39 |
| mgz | why? what are you actually *doing*... | 17:39 |
| JPeterson | same thing as bzr cat | 17:39 |
| mgz | no, that's not what you're doing | 17:40 |
| mgz | it's what you're trying in order to do something else | 17:40 |
| mgz | in absense of answer, I shall choose to believe you're writing a script to live-patch a locked down device | 17:49 |
| mgz | in which case, just stick the file you want up on a url you control, and write a cronjob that updates it from the branch | 17:50 |
| mgz | loggerhead doesn't promise stable download urls, so hardcoding something may break in future. | 17:51 |
| mgz | if that's not what you want, sorry, but I can only guess so far | 17:51 |
| === beuno-lunch is now known as beuno | ||
| alkisg | Hehe fun, two people asking the same question at the same time... | 18:08 |
| JPeterson | how do i edit in tbzrcommand.exe --command=diff? | 18:52 |
| JPeterson | i mean in the tbzrcommand.exe --command=dif window | 18:52 |
| JPeterson | why is the diff window read only? | 18:53 |
| JPeterson | someone isn't thinking? | 18:53 |
| JPeterson | how does http://doc.bazaar.canonical.com/bzr-0.10/bzr_man.htm#bzr-diff-file tell me how i ignore lines like "=== modified file 'src/templite/__init__.py' (properties changed: -x to +x)"? | 19:07 |
| JPeterson | should i use "bzr diff|filterdiff --clean"? | 19:10 |
| fullermd | I don't think I understand the question. But why are you reading docs from a 6 year old release? | 19:11 |
| JPeterson | how do i bzr commit --amend? | 19:29 |
| jelmer | JPeterson: 'bzr uncommit && bzr commit' | 19:30 |
| JPeterson | thx | 19:31 |
| tbf | how would i figure out the name of the current co-located branch - by looking at the data in the .bzr folder | 19:45 |
| tbf | need that information for display in qtcreator. calling "bzr nick" old would work as fallback there, since launching python and all takes too long for the purpose | 19:46 |
| JPeterson | how do i revert all (properties changed: -x to +x)? | 20:07 |
| jelmer | JPeterson: bzr revert | 20:08 |
| JPeterson | jelmer: how will it know to only revert (properties changed: -x to +x)? | 20:09 |
| jelmer | JPeterson: it would revert all changes | 20:10 |
| JPeterson | oh | 20:10 |
| JPeterson | a bug report say ""bzr status" will set every X bit in the branch." is this true? | 20:27 |
| JPeterson | seems dumb | 20:27 |
| mwhudson | seems unlikely | 20:28 |
| JPeterson | i belive this is the scenario: call bzr cli in cygwin. | 20:29 |
| JPeterson | well first time i've used bzr and it's already shown to be written by retards beyond comprehension | 20:30 |
| JPeterson | does this make sense to you `bzr: ERROR: Path "/cygdrive/c/Files/Source/Programs/calibre/repo/src/templite/__init__.py" is not a child of path "/cygdrive/d/Files/Source/Programs/calibre/repo"`? | 20:35 |
| danielbrauer | c vs. d? | 20:35 |
| JPeterson | thx | 20:37 |
| JPeterson | why can't i revert the "(properties changed: -x to +x)"? | 20:37 |
| JPeterson | bzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`; bzr diff still return ""(properties changed: -x to +x)"" | 20:38 |
| danielbrauer | Sorry, I'm just getting started with bzr myself. | 20:38 |
| JPeterson | i believe this question has been discussed here https://bugs.launchpad.net/bzr/+bug/248333. and i added a rhetorical question "When you wrote the code in question, did you test tbzrcommand.exe and cygwin /usr/bin/bzr on the same repo?". | 20:53 |
| ubot5 | Ubuntu bug 248333 in Bazaar "[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux" [Low,Confirmed] | 20:53 |
| JPeterson | sadly, the answer to that is no | 20:54 |
| JPeterson | i wonder if the repo maintainer will reconsider applying the patch when it changes the x bit on 888 files in the repo | 20:55 |
| JPeterson | i hope it doesnt reduce the possibility that my patch is accepted | 20:56 |
| JPeterson | maybe i wont seem like an absolute retard because of this bug | 20:56 |
| === the-other-carif_ is now known as carif1 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!