/srv/irclogs.ubuntu.com/2012/10/22/#bzr.txt

delinquentmejelmer, know of a way to branch off of a particular revno of a bzr repo?00:05
spivdelinquentme: "bzr branch -r REVNO"00:06
jelmerdelinquentme: bzr branch -rX00:07
delinquentmelol am i supposed to get nothing returned when I run a bzr status for a newly branched dir?00:30
bob2what do you think it should show?00:34
bob2you have no local changes00:34
delinquentmeshould it not say that ?00:35
bob2no00:35
delinquentmesounds like a quiet fail00:35
delinquentmeit should :D00:35
bob2it's not a quiet fail, it had nothing to say, so said nothing and exited with 000:35
jelmerI think it says "X revisions branched." usually?00:35
bob2bzr branch does, delinquentme is talking about 'bzr status' in the branched dir00:36
jelmerbob2: ah, whoops - sorry00:36
mgzmorning!08:01
fullermdETOOPERKY08:02
vilahi there08:35
fullermdWhere??08:36
mgzbehind you!08:38
fullermdOh, good.  I could use a good backrub.08:41
* vila rubs09:09
=== AfC1 is now known as AfC
fullermdbzr ping ->  Headers: {'Software version': '2.0.3'}14:39
fullermdFurrfu   :|14:40
mgzheh, against which server fullermd?14:42
fullermdSourceforge14:42
fullermdBut hey, their docs claim they support bzr 1.10, so in relative terms...14:43
crazydiphaving 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
fullermdA 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
fullermdBasically the [im]mortal equivalent of something like "bzr diff -c2 | patch -R".14:52
fullermdYou 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
fullermdThat'll stage up a "reverse" of rev 2, which you can then check and fix any conflicts and test and commit.14:53
fullermdThen you can do the same for rev 4.14:53
crazydipdoes the trailing . in "merge -r 2..1 ." mean "all files" in -r 2..1?14:54
fullermdNot exactly.  It tells merge what branch to 'merge' from.  In this case, the branch you're sitting in.14:55
crazydipok :)14:55
crazydipand can I merge both 2..1 and 4..3 before commiting? Like with "merge -r 4..3 . --force"?14:57
fullermdYou could.  My impulse would be not to, just for cleanliness.14:57
crazydipthat's some great and clear advice! thank you fullermd!14:59
fullermdThat's 'cuz I'm clearly great   8-}15:01
crazydipI did not want to say anything and look too much like a newb, cause it was so obvious :D15:02
fullermdOh, don't worry, we never point and laugh at anybody on this channel.15:05
fullermdWe've got a whole separate channel for that.15:05
crazydip#bzr-lolz? :)15:05
fullermdThat'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
danielbrauerfullermd: 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
fullermdIt'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
fullermdThe usual fallback involves creating a new history without the thing you want to obliterate, and flag-day'ing everybody over to it.15:53
danielbrauerI could see it being difficult to resolve if you've got a lot of branches.15:53
fullermdJust 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
fullermdStill, easier is a long way from "easy".15:55
fullermdIt 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   ;p15:55
danielbrauerI'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
crazydipi'm so glad we have dvcs's and can just ignore aweful cvs :)15:58
fullermdNo, a set of branches can have any arbitrary relationship to each other.  Alternately, they have _no_ necessary relationship to each other.15:59
fullermdIn a technical sense, any two branches are related based on what revisions they do/don't share.15:59
fullermdOf course, _socially_ speaking, in any project you probably have something rather like a hierachy.16:00
fullermdBut that's a matter of your convention and human/social necessity, not tool technical necessity.16:00
danielbrauerOk. 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
fullermdYou might find some of http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs useful, particularly starting with http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief16:01
danielbrauerOk, 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
crazydipdanielbrauer: 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 technical16:12
danielbrauerRight. 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
danielbrauerIs the difference a matter of "binding"?16:15
crazydipdanielbrauer: 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
danielbrauerWill do, thanks16:15
fullermdPlz to ignore binding.  It'll only confuse things way more.16:15
danielbrauerOk, I'll do that too. (:16:16
fullermdcheckout/branch and merge/commit are definitely not at all the same thing.16:16
danielbrauerNo, I assumed not. It's just that so far I've only read explanations that involve similar-looking arrows.16:17
fullermdI'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
danielbrauerYeah, the inherent unrelatedness of revisions is something I hadn't gathered before.16:17
fullermdCommit is a way (almost the only way, ignoring exotic situations, which you should) that Revisions get created.16:17
fullermdEverything else is just a matter of how they get shared around after being created.16:18
fullermdOh, Revisions are very strongly related.  They're just the _only_ thing that relates.16:19
fullermdBranches 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
danielbrauerNo problem. I appreciate the time.16:21
fullermdIf 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
fullermdSo it's only the action-type ones you should worry about right now.16:22
danielbrauerYeah, 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
danielbrauerI 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
danielbrauerThat's not obvious from the beginning of the manual.16:23
fullermdWe 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
danielbrauerOk.16:23
fullermdpush 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
danielbrauerOk. Presumably the branches have to be related in some way for that to work?16:24
fullermdYes.  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
fullermdOr alternately phrased, only one side can have changes the other doesn't.16:25
danielbrauerGot it.16:25
fullermdIf both have changes the other doesn't (they've diverged), you need to use merge to pull them together.16:25
danielbrauerWhat's the difference between update and pull?16:26
fullermdAnd 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
fullermdLet's ignore update for right now; that'll just confuse things a bit.16:27
danielbrauerOk, that's similar to svn's merge. The result is a bunch of modifications to your working copy.16:27
fullermdI believe so, yes.  It leaves you with a stack of changes to check over, and then commit.16:27
danielbrauerBut I guess merge preserves more history in Bazaar?16:27
fullermdYes.  The history models are somewhat different.16:28
jmlhttps://code.launchpad.net/~jml/bzr/rubberstamp/+merge/13085016:28
fullermdIn svn, history is basically linear (and then there's some extra metadata that gets written about merges, off to the side)16:28
danielbrauerRight.16:29
fullermdWhereas in bzr (and most other major DVCSen), history is a DAG.16:29
fullermdAnd if that meant something to you, we get to shortcut a lot of explanation.16:29
danielbrauerYup.16:29
danielbrauerYeah, I16:30
danielbrauer'm a CS graduate. They only taught us CVS but I do know some theory. (:16:30
fullermdEggselent.16:30
fullermdSo every revision is a vertex in the graph of history.16:30
fullermdAnd it's got some number of edges sprouting out of it pointing at other revisions, which are its parents.16:31
fullermdIt may have 0, which means it's an initial revision you created from nothing (e.g., after a 'bzr init')16:31
danielbrauerOk. Now should I be thinking about "history" as a single branch, or all related branches from a repository?16:31
fullermdIt 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
fullermdMmm.  Both, in a way.16:32
fullermdOr, 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
fullermdSo 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
danielbrauerThat makes sense.16:34
fullermdSo, 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
fullermdIf they both have the same head, they're identical and functionally interchangeable.16:34
fullermdIf 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
fullermdIf 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
danielbrauerOk. 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
fullermdRight.  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
danielbrauerGot it.16:38
fullermdSo 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
danielbrauerOk. 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
fullermdRight.  Which is impossible, by the data model.16:40
fullermdSo 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
danielbrauerOk. 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
fullermdNot exactly right on the svn side, but right on the limitations of the DVCSen.16:42
danielbrauerOk. 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
fullermdEach 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
fullermdIn 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
fullermdIf 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
danielbrauerOk. So I could set out to merge Mozilla and gcc?16:49
fullermdIt's perfectly possible.16:49
fullermdThe result might be silly, but it's possible   :)16:49
danielbrauerI'll get started right away.16:49
fullermdYou'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
fullermdWhich is a perfectly valid graph.16:50
danielbrauerUnderstood.16:50
fullermdActually, 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
danielbrauerWhat are some examples?16:51
fullermdThink of the process "import a vendor branch"; that's what you're doing in that case.16:51
danielbrauerOh, right.16:51
danielbrauerSo kind of like an external, but you're actually folding it into your branch?16:51
fullermdSo 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
danielbrauerAnd then you could merge future revisions of those libs into your branch later if that's what you want.16:52
fullermdRoughly, yeah.  You can think of an external as "include by reference", whereas merging it in is "include by value".16:52
danielbrauerRight.16:52
fullermdRight.  Especially useful if I don't actually want libthis, but rather libthis-plus-some-local-changes.16:52
alkisgHi, 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-defaults16:53
alkisgI'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
fullermdThe local changes just happen in my branch, and the pristine libthis's merge cleanly (I hope)16:53
danielbrauerSurprise API rewrite!16:53
fullermd"API" is the sound you make when it changes out from under you.16:54
fullermdalkisg: 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
alkisgfullermd: 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
danielbrauerOk, lunch now. Thanks for the explanations. It's really helped, along with the Fuller ones.17:03
JPetersonwhats 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
JPetersonit returns "The resource could not be found. "17:19
JPetersonsearching for "launchpad wget repo file" doesnt return an answer unfortunately. sadly and answer would be valuable to me.17:21
mgzJPeterson: `bzr cat -d lp:calibre src/calibre/libwand.py`17:23
mgzunless you're also trying to build an iso and don't have anything installed...17:23
JPetersonthx. what if i have curl but not bzr?17:24
mgzdisappointingly inefficient still, and ick, that's some ugly ctypes17:25
mgzJPeterson: `curl https://launchpad.net/bzr/2.5/2.5.1/+download/bzr-2.5.1.tar.gz`17:28
JPetersonwhat if dont have write access?17:29
mgzbut 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
mgzit's thought-experiment day apparently17:30
fullermdI 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
mgzJPeterson: what are you actually doing, out of curiosity?17:34
JPetersonreading a launchpad repo file17:34
mgzJPeterson: on the grand scale17:35
mgzwhen you have completed all the little steps that include reading this file, what will you have done?17:35
JPetersonsame thing as bzr cat17:35
JPetersonthe 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 url17:38
JPetersonbut i would like a shorter url than that17:38
JPetersonone that only include the path. not revision.17:39
mgzwhy? what are you actually *doing*...17:39
JPetersonsame thing as bzr cat17:39
mgzno, that's not what you're doing17:40
mgzit's what you're trying in order to do something else17:40
mgzin absense of answer, I shall choose to believe you're writing a script to live-patch a locked down device17:49
mgzin which case, just stick the file you want up on a url you control, and write a cronjob that updates it from the branch17:50
mgzloggerhead doesn't promise stable download urls, so hardcoding something may break in future.17:51
mgzif that's not what you want, sorry, but I can only guess so far17:51
=== beuno-lunch is now known as beuno
alkisgHehe fun, two people asking the same question at the same time...18:08
JPetersonhow do i edit in tbzrcommand.exe --command=diff?18:52
JPetersoni mean in the  tbzrcommand.exe --command=dif window18:52
JPetersonwhy is the diff window read only?18:53
JPetersonsomeone isn't thinking?18:53
JPetersonhow 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
JPetersonshould i use "bzr diff|filterdiff --clean"?19:10
fullermdI don't think I understand the question.  But why are you reading docs from a 6 year old release?19:11
JPetersonhow do i bzr commit --amend?19:29
jelmerJPeterson: 'bzr uncommit && bzr commit'19:30
JPetersonthx19:31
tbfhow would i figure out the name of the current co-located branch - by looking at the data in the .bzr folder19:45
tbfneed 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 purpose19:46
JPetersonhow do i revert all (properties changed: -x to +x)?20:07
jelmerJPeterson: bzr revert20:08
JPetersonjelmer: how will it know to only revert (properties changed: -x to +x)?20:09
jelmerJPeterson: it would revert all changes20:10
JPetersonoh20:10
JPetersona bug report say ""bzr status" will set every X bit in the branch." is this true?20:27
JPetersonseems dumb20:27
mwhudsonseems unlikely20:28
JPetersoni belive this is the scenario: call bzr cli in cygwin.20:29
JPetersonwell first time i've used bzr and it's already shown to be written by retards beyond comprehension20:30
JPetersondoes 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
danielbrauerc vs. d?20:35
JPetersonthx20:37
JPetersonwhy can't i revert the "(properties changed: -x to +x)"?20:37
JPetersonbzr revert `bzr diff|grep 'properties changed'|awk '{print $4}'`; bzr diff still return ""(properties changed: -x to +x)""20:38
danielbrauerSorry, I'm just getting started with bzr myself.20:38
JPetersoni 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
ubot5Ubuntu 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
JPetersonsadly, the answer to that is no20:54
JPetersoni wonder if the repo maintainer will reconsider applying the patch when it changes the x bit on 888 files in the repo20:55
JPetersoni hope it doesnt reduce the possibility that my patch is accepted20:56
JPetersonmaybe i wont seem like an absolute retard because of this bug20:56
=== the-other-carif_ is now known as carif1

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!