lifelessigc: whats the testing guide and why isn't it part of the dev guide?00:10
lifelesssorry if that came across picky, I'm just a little surprised / concerned about fragmentation00:11
igclifeless: someone moved it out (vila maybe)00:11
igclifeless: http://doc.bazaar-vcs.org/developers/00:12
lifelessso this is a terminology thing00:13
lifelessthats all dev guide to me00:13
lifelessand I suspect to poolie as well00:13
lifelessjust chapters in the dev documentation00:13
Peng_Is http://bazaar-vcs.org/bzr/.bzr/repository/packs/ really badly compressed, or did I accidentally misplace most of my repo while upgrading to 2a?00:20
Peng_Oooh. Never mind. That is a 1.9-format repo. Hm.00:21
Peng_Ohh! http://bazaar-vcs.org/bzr/bzr.dev/ is a branch reference now. Clever!00:22
Peng_Confusing, too.00:22
Peng_So lp:bzr is now the official location for bzr.dev?00:23
Peng_What should I set bzr to use as the public/submit branch?00:24
lifelesscheck the docs ;)00:25
Peng_.....Which docs? :D (kidding)00:25
lifeless[I've paged it out]00:25
Peng_The doc directory in the source tree doesn't help.00:26
Peng_I'll keep the public and submit branches set to bazaar-vcs.org for now, then.00:28
lifelessPeng_: HACKING.txt00:31
lifelesslook for locations.conf00:31
Peng_Ah, thanks. That didn't help very much, though. I'm not a PQM user.00:36
Peng_And LP is open source now. I have missed a lot!00:37
lifelessPeng_: well, lp:bzr then ;)00:39
Peng_Literally "lp:bzr", or the http or bzr+ssh location that points to?00:40
lifelessif you just want 'bzr send' to work00:43
pooliehi all00:55
pooliewelcome back igc00:55
igcthanks poolie00:55
spivGood morning.00:55
Peng_Good morning. Or whatever. :)00:55
igchi spiv00:55
Peng_Is it morning?00:55
igchi Peng_00:55
igcPeng_: it is here :-)00:56
thumperhi ho01:40
thumperwhat is the simplest way to allow people to push to a machine with bzr+ssh but not to have shell access?01:40
Peng_There's a script, contrib/bzr_access or somesuch.01:41
lifelessauthorized_keys policy01:41
lifelessand or that script01:41
thumperoh kay...01:41
thumperwhich is easier / more configurable?01:42
lifelesslaunchpad :P01:42
thumperlifeless: haha01:42
Peng_He's right...01:42
thumperwhere does the package install the contrib dir?01:42
lifelessI don't think it does01:42
thumperPeng_: it is for some friends polytech work01:42
thumperno project01:42
thumperand they don't want it public01:42
thumperand I don't want them poking around my machine01:43
Peng_Umm. Install Launchpad on your machine? :D01:43
Peng_You could just give them SFTP access.01:43
SamB_XP_Peng_: that isn't great01:44
thumperthis should be an easy thing to set up for bzr01:44
thumperI've been frustrated that it wasn't easier01:44
thumperlike sticky group bits01:44
SamB_XP_Peng_: you'd want to give 'em smart server access too ...01:44
thumperand umasks01:44
thumperet al01:44
thumperI think we should be able to set something in the locations.conf (or something)01:44
thumperand have the smart server set the right groups01:44
Peng_SamB_XP_: I know01:45
pooliespiv, hello01:58
spivpoolie: hi01:59
spivpoolie: I've done a couple of rounds of "do something to a bug" "gar, file a bug on launchpad" this morning.02:00
spivpoolie: I have a fix for the 2 hpss vfs calls on incremental push; I've played a bit with trying to anticipate future requirements with the new verb I'm adding, but decided against it so I'll just submit the simple fix.02:01
poolieigc, to answer the only other question on our agenda02:03
pooliesee my mail to emma on friday, i'm aiming to get the site up this week02:03
pooliefrom a shared branch deployed to escudero02:03
pooliespiv, cool02:03
igcpoolie: thanks02:03
poolieor you can if you get to it first02:03
pooliespiv, we still seem to get a lot of 'medium(?) in use' errors02:03
pooliemaybe this should be handled under -Dcleanup but perhaps there's something else we should do that would avoid them obscuring the real error?02:04
spivpoolie: hmm02:05
pooliemy thoughts exactly :)02:10
pooliemaybe we'll try -Dcleanup first and then see what happens02:10
poolieor more importantly, putting a choke point for all cleanups02:10
lifelessspiv: whats trigering vfs on incremental push ?02:13
spivlifeless: "cannot update remote workingtree" warning02:13
lifelessmeep yes I saw that02:14
lifelesswhat was it?02:14
spivpush explicitly checks for a working tree so that it can issue that warning, and we have no HPSS way to find a working tree.02:14
spivIt doesn't actually care what format or anything it is, just whether or not there is one.02:15
spivSo I've made a new BzrDir.open verb that returns a yes/no for the presence of a workingtree in this bzrdir.02:16
lifelesshave you seen spurious outputs of that warning btw?02:16
spivI could have made a has_workingtree verb, but may as well cut out the roundtrip and take the opportunity to slightly decruft the BzrDir.open verb :)02:16
spivNo, I don't think so.02:17
lifelessso, I think has_workingtree would be more precise02:17
lifelessbut as we don't support working with them remotely anyway02:17
lifelessdoing what you've done is fine02:17
lifelesswhat cruft are you deing?02:18
lifeless[if its the declarative capabilities, I'm not sure we want to remove them]02:18
spivThe current BzrDir.open verb squashes some error conditions into just 'yes'/'no', for backwards-compat reasons.02:18
lifelessI see, cool.02:19
igcpoolie: one thing I forgot to discuss on the phone: elmo's email re the karmic chroot02:20
igcpoolie: one of us should reply02:20
zsquarepluschmm, why does multi-pull try to pull data from a file URL when i want to fetch from a bzr+ssh URL? even worse, it sees the path the branch was on the other machine from which i first pushed it up02:23
spivzsquareplusc: it uses the remembered pull locations, IIRC.  You can use "bzr pull --remember NEW_URL" in those branches to change that.02:24
zsquarepluschm, doesn't this make the multi-pull more or less useless? it apparently manages to find these branches on the remote URL but then it turns to a completely different location to download?!?02:26
spivzsquareplusc: no, it just does the same as "bzr pull" with no arguments would do in each of the individual branches.02:27
spivWhich is often the right thing, and if it's not it's usually easy to use either --remember or edit your locations.conf to make it do the right thing.02:28
spivIt would be nice to have a "pull all of these from *over there* just this once" feature too, though.02:28
zsquarepluscwell the branches were created on one machine, converted from CVS. i pushed them to a repo on sf.net. so i have to manually touch each of these again, re-push etc :(02:30
zsquarepluscspiv: i disagree that it is doing the right thing in this case. i have no local copy yet, just and empty shared repo. i'd certainly expect that multi-pull downloads from the URL i'm giving it not from anywhere else.02:33
zsquarepluschow do i see the saved push location? bzr info?02:36
zsquarepluscbecause i don't see it there on the branch i pulled (one of those were multi-pull failed)02:36
spivzsquareplusc: if you don't have a branch yet, then pull (and multi-pull) aren't the commands you need.02:38
zsquareplusci don't see a multi-branch :/02:38
spivYeah :(02:38
spivI agree there are things we could support better, I'm just explaining that multi-pull is doing what it was designed to do.  It would be nice to have multi-branch or similar.02:39
spivWe're actually planning to rethink how we deal with groups of branches for 3.0, because we know we're a bit lacking.02:40
zsquarepluscwell if it would just fail, OK. what's irritating me is that it somehow remembers a local path on my other machine02:40
zsquareplusci ran a bzr info on the branch i originally pushed, it has that file URL there listed as parent02:41
spivzsquareplusc: that does sound weird.  multi-pull walks all the subdirectories of the directory you run it in looking for branches to pull, perhaps one of those has a branch with that info?02:42
spivWhatever multi-pull does with an individual branch you ought to be able to reproduce with plain "bzr pull" on that branch.02:42
zsquareplusci gave it the URL of the remote repo, so it apparently walks trough those :/02:43
spivThat does sound likely to confuse, yes.02:43
spivI guess that's like doing "bzr pull -d REMOTE_URL"...02:43
zsquarepluscthat the branches remember that file:// parent does not hurt? at least the fresh branch i made from the remote repo (using bzr branch) does not list it anymore, it has the remote repo URL as parent, which makes more sense02:47
zsquarepluscand is there a special reason that when i bzr branch, that same URL is not right away saved as push, pull and merge location? at least the way i was using it, that would have been helpful02:49
SamB_XP_spiv: yeah, it does seem a bit silly for it to be attempting to pull *into* an HTTP url ;P02:56
spivSamB_XP_: there might be a smart server there :P03:01
zsquarepluscit was a bzr+ssh URL03:01
SamB_XP_oh, that's a bit less dumb then03:02
lifelessI thought that the bug with bzrlib/bzrlib/*.so was fixed?03:09
zsquarepluschmm. getting access denied on  c:\...\temp\xxx.pag03:10
zsquareplusci made a bash script that does several bzr branch(es) now when i run it under cygwins bash it prints that its connected using ssh and then the error about access denied on the temp file :(03:16
zsquarepluscwhen i run the command manually it fails the same way - when run in a bash shell. it works in a cmd.exe :/03:24
zsquarepluscit seems to be paramiko/win_pageant.pyo:121 that causes the error (official bzr 1.15 windows distribution)03:35
=== timchen1` is now known as nasloc__
* igc lunch04:48
pooliespiv btw bug 432993 is the kind of thing i was referring to earlier05:13
ubottuLaunchpad bug 432993 in bzr "TooManyConcurrentRequests when failing to connect over ssh" [High,Confirmed] https://launchpad.net/bugs/43299305:13
* igc medical appointment - bbl05:38
thumperi can haz hard linkz agan plz?06:01
lifelesspoolie: you're working on a bug script?06:01
lifelessthumper: what do you want them for?06:02
pooliei am06:02
thumperlifeless: hardlinking working copy files is not currently supported in <WorkingTree6 of /home/tim/src/lp/bmp-notification-recipients>06:02
thumperlifeless: just how I work06:02
lifelessthumper: tell me more06:03
thumperlifeless: I have light weight checkouts of devel06:03
thumperlifeless: and I build new branches using 'cbranch --lightweight --hardlink'06:04
thumperlifeless: now about 2006:04
lifelesshave you considered using switch ?06:04
thumperI use pipelines06:04
lifelessWhat doesn't it do/does wrong for you?06:04
thumperbut I like to keep my work in meaningful directories06:05
thumperit adds context for me06:05
thumperI started with switch originally06:05
lifelessso I use meaningful directories06:05
thumperbut I found I had too many copies on the go06:05
lifelessand switch06:05
lifelessdo you mean 'you forgot where you were'06:05
lifelessor 'you actually needed multiple work areas at once due to $thing'06:06
thumperlifeless: it had to do with work that was in various states of review06:06
thumperlifeless: I often have tests running in one branch06:06
thumperwhile hacking in another06:06
poolie   888 Confirmed06:06
poolie   353 Triaged06:06
poolie   265 New06:06
poolie   147 Incomplete06:06
poolie    47 In Progress06:06
poolie    17 Fix Committed06:06
thumperor even running LP locally in another06:06
lifelesspoolie: welcome to API's06:06
pooliemm, i have poked at them before06:07
thumperlifeless: I also found that using TAGS, with multiple directories, I need different emacs buffers06:07
pooliethe vodka is strong but the meat is no good06:07
thumperlifeless: or I can get jumped around into the wrong directory06:07
lifelessthumper: would it be a good idea for 'bzr switch' should incremental-update TAGS?06:08
lifelessthumper: here's where I'm coming from: we're doing UI overhaul around groups of branches.06:08
thumperI don't pretend to understand TAGS06:08
thumperI know06:09
lifelessthumper: I suspect many folk have 'lightweight + switch' as key building blocks in how they want to tackle that.06:09
thumperI guess I use my checkouts as a kinda "work in progress" list06:10
lifelessthumper: so I want to understand the friction you felt more06:10
thumperI delete them when they are merged06:10
thumperI use multiple checkouts for various reasons06:10
thumperI like to be able to run against trunk without switching my current work06:10
pooliethumper: so just click affectsmetoo on the bug and then... oh :)06:10
thumperto perhaps test stuff06:10
pooliemore seriously, we could look at in content filtering06:11
thumperand sometimes running long tests locally while wanting to hack other stuff06:11
thumperso I need more than one concurrent checkout06:11
thumperone I had more than one06:11
thumperI found that I wanted meaningful directory names06:11
thumperthe easiest way I found was to have lightweight checkouts for my work06:12
thumperand moved to cbranch06:12
thumperfrom there to hardlink06:12
thumperperhaps having a way to tag branches in a local repo as in various states would help me06:12
thumperso I could easily see which branches I have locally that aren't merged06:13
thumperwithout having them all in their own checkouts06:13
mwhudsonfwiw, i work almost exactly like thumper06:13
thumperas long as I could list them easily06:13
lifelessthumper: I use directories to tag branches06:13
thumperlifeless: inside the repo?06:13
lifelessthumper: mkdir pending; mkdir review; mkdir experimental06:13
abentleyfwiw, thumper works almost exactly like me :-)06:14
mwhudsoni don't actually have any real problems with bzr here, as 'make build' takes far longer than tree building :(06:14
thumperI don't have trees in my repo06:14
thumperit seems ick to me06:14
thumpermwhudson: true06:14
lifelessthumper: thats not anything to do with trees :)06:14
lifelessthumper: I put branches under there06:14
thumperlifeless: but if you have a lightweight checkout, and you move the branch06:15
thumperlifeless: how do you reconcile that?06:15
lifelessbzr switch --force06:15
lifelessbut it happens rarely06:15
lifelessas I have only a few checkouts06:15
lifelessand usually state changes are also when I need to stop editing (or conversely start editing) branches06:16
thumperlifeless: I got my workflow from jamesh06:16
thumperlifeless: when I first started using bzr06:16
lifelessthumper: I'm not criticising it!06:16
thumperlifeless: I'm not saying you are06:16
thumperlifeless: I'm trying to give context06:16
lifelessthanks ;)06:17
thumperlifeless: part of it is "this is how I was taught"06:17
thumperlifeless: I have thick skin, you have to be a hell of a lot more direct for me to think you are criticising :)06:17
lifelessAll the rugby06:18
thumperlifeless: I didn't start rugby until I worked in the UK06:18
thumperlifeless: never played in NZ before that06:18
RenatoSilvawhat's the recommended workflow when working on a feature branch while trunk keeps actively updated?06:36
lifelesshack;hack; commit; merge trunk; check for regressions; commit; hack; hack; loop06:37
RenatoSilvaI'm using launchpad, I have one branch in rev 18, and other in rev 21 which is the trunk. I'm afraid that when I merge the former (likely to keep at rev 18) with the latter, that could be at rev 25 for example, well I'm afraid I have problems...06:39
RenatoSilvawhat are regressions?06:39
lifelesswhen things stop working06:39
RenatoSilvaand so I need to keep in sync with the target branch?06:39
lifelessup to you06:40
lifelessyou asked for recommended ;)06:40
RenatoSilvahum so it is recommended to avoid regression?06:40
RenatoSilvathe more diffs between branches, the more likely the merge will break code?06:40
* RenatoSilva how merges are get done is still an enigma for him06:41
bob2RenatoSilva: avoiding regressions is a fancy way of saying 'don't introduce bugs' :)06:46
bob2RenatoSilva: I dunno if falling behind and having to do larger merges is more likely to introduce bugs (probably), but it's also harder and more likely to conflict06:47
lifelessand bugs can happen when you merge.06:47
spivRenatoSilva: basically, bzr compares the history of all the changes in the two branches, and applies the changes that are present in the merge source but not yet present in the target.06:47
RenatoSilvabob2: yeah, I don't know about bugs either (generated by the merge itself?)06:48
spivRenatoSilva: but bzr is just software; the way it understands changes is by seeing which lines of text have changed, rather than understanding that e.g. "function X was renamed to Y", so it's possible that the result bzr merge will produce something other than what a human would have done if they were applying those changes manually.06:49
bob2RenatoSilva: by combining your code with the trunk - e.g. if you modified some function to introduce a bug06:49
mwhudsonRenatoSilva: the classic thing is stuff like adding a required argument to a function in one branch while adding a call to that function in another06:49
mwhudsonRenatoSilva: both branches are correct, but the combination is not, and you'd need to be waaay cleverer than any vcs tool is today to figure that out automatically06:50
RenatoSilvaspiv: that's what I imagined, for example if I merge branch X in rev 19 with trunk rev 21, where they have diverged at rev 17, so bzr will take revs 18 and 19 and try to apply the diffs to rev 21 on the trunk, right?06:50
spivRenatoSilva: and sometimes changes in the two branches are simply incompatible as-is, e.g. one branch may add a new argument to a function, and the other may add a different new argument instead.  (or mwhudson's example, which is similar)06:51
lifelessRenatoSilva: the mechanics of the merge - bzr will merge unmerged work.06:51
lifelessRenatoSilva: you should just try; nothing like experimentation to help you see06:51
spivRenatoSilva: if you merge X into trunk, then yes.06:51
spivRenatoSilva: (although not via diffs, precisely; diffs don't handle renames and bzr does, for instance)06:52
spivHmm, well, I guess diffs can do renames.06:52
spivdiffs aren't so good for changes to symlinks or binary files, though :)06:53
Peng_Well, merging isn't so good for symlinks or binary files.....06:55
RenatoSilvaspiv: ok I don't mean `diff`s are generated, I just think it's sort of magic :)06:55
spivPeng_: yeah, but at least it DTRT when only one side has changed them.06:56
Peng_spiv: Oh, cool.06:56
RenatoSilvaPeng_: for bin files you have to choose between one and another versions right? there's no merge for them ...06:56
Peng_RenatoSilva: Well it's totally theoretically possible to develop merge tools for binary files.06:57
Peng_RenatoSilva: Merging really isn't scary, and it's a major part of using a DVCS.06:57
Peng_RenatoSilva: Even if things go horribly wrong, you can just "bzr revert".06:57
RenatoSilvalifeless: well I have merged a few times, I just see it as magic :) (just curious about how it works -- because of the initial issue)06:58
RenatoSilvaspiv: well I think something similar to a merge-directive is used07:01
spivRenatoSilva: well, if a file originally had a series of lines ABCD, and one branch changed it to ABC, and the other changed it to AECD, then merge would result in AEC.07:01
RenatoSilvaspiv: except that the commits are "packaged" under another one07:01
RenatoSilvaspiv: AEC? weird, so bzr tries to do same-line merges? o.O07:02
spivRenatoSilva: no, by "ABCD" I mean four lines07:03
spivRenatoSilva: just using a very compact notation because IRC isn't really designed for multi-line examples :)07:03
RenatoSilvaok :)07:04
RenatoSilvaso it is recommended that as I update trunk, I do a bzr pull in the other branch?07:04
lifelessno, you can't07:05
spiv(In principle a merge algorithm can work with sequences of bytes rather than sequences of lines, but for various reasons lines tend to be a good tradeoff for performance and human-intelligible results for source code)07:05
lifelessbecause the other branch has different changes07:05
RenatoSilvalifeless: hum you can't pull from a diverged branch, right07:07
RenatoSilvaso what should I do?07:07
RenatoSilvamerge trunk into the other?07:07
lifelessyes; as I said waaaay above :)07:07
RenatoSilvalet's use an example07:08
RenatoSilvabranch X rev 19, diverged from trunk at rev 17, and trunk is at rev 2107:09
RenatoSilvaso I merge trunk into X, and X get a new rev 20 { trunk 18-21  } ?07:09
lifelessRenatoSilva: yes07:09
lifelesscd X; bzr merge trunk; <check for regressions>; bzr commit -m 'merge trunk'07:10
RenatoSilvaand when I'm done I merge X into trunk, that gets a rev 22 { X 18, 19, 20 { trunk 18-21 }  } ?07:11
RenatoSilva* trunk, which gets07:11
spivNot sure exactly what you mean by that notation.07:11
RenatoSilvaspiv: that's the only way I can see it :(07:12
spivIt's tip revision, rev 22, would have two parents, trunk's 21 and X's 20.07:12
RenatoSilvaspiv: rev 22 of trunk will contain 3 revs from X: 18, 19 and 20, where 20 is a merge with trunk07:12
spivRenatoSilva: "contain" isn't really the right relation.07:12
spivRenatoSilva: "has parent" is the relation.07:13
RenatoSilvawhat's a tip revision?07:13
spivRenatoSilva: the most recent revision in that branch.  The "tip" of the branch :)07:13
lifelessthe most recent commit on a branch07:13
spivAlso known as "head"07:13
spivRenatoSilva: have you seen the output of "bzr viz" (if you have the bzr-gtk plugin) or "bzr qlog" (if you have qbzr)?07:14
RenatoSilvaspiv: I think if you explain me using my notation I could easily understand :)07:14
* RenatoSilva trying to understand "It's tip revision, rev 22, would have two parents, trunk's 21 and X's 20."07:15
spivRenatoSilva: I can't, because I think the way you read your notation presumes a view of the system that isn't accurate07:15
lifelesspoolie: so whats your bug thing?07:15
davidstraussspiv: I'm pretty sure that notation means rev 22, which contains X's 18, 19, 20. X's 20 contains trunk's 18-21.07:15
lifelessdavidstrauss: contains is the problem though :)07:15
lifelessdavidstrauss: as revisions are not containers for revisions07:15
davidstrausslifeless: what does it mean when they're nested in the log output, then?07:16
spivdavidstrauss: a) what lifeless said, b) that reading would confirm my suspicion that it's an inaccurate model for bzr07:16
lifelessdavidstrauss: non-left hand parent07:16
lifelessdavidstrauss: e.g. a merge occured, and the revision that is indented was not present in the left hand ancestor of the above revision07:17
RenatoSilvalifeless: last time I saw a merge commit the revisions merged were showing "inside" the merge revision07:17
spivRenatoSilva: so, a commit has links its parent(s), and they are links rather than copies.07:17
spivRenatoSilva: and those parents in turn have links to *their* parent(s), and so on.07:18
RenatoSilvalifeless: I have never seen one for the scenario I mentioned though07:18
lifelessRenatoSilva: yes, they will show like that; this indicates 'merged by' not 'contained within'07:18
poolielifeless: i'd like to make the state of the queues more visible07:18
pooliemaybe with a graph of open bugs etc07:18
poolieand to have a list of tags perhaps07:19
spivRenatoSilva: so you can draw a diagram of the revision ancestry back to the start (a revision with no parents) by repeatedly following those links.07:19
poolieand just generally get a better feel for how much things can be extended using apis07:19
lifelesspoolie: what I'd love: a google appengine web page; showing the bzr project [perhaps project-group even] bugs in my preferred sort order07:19
davidstraussspiv: so replace "contains" with "has children linking to it, which are:"07:19
davidstraussspiv: is that accurate?07:20
spivdavidstrauss: if so, that notation is inaccurate, and should be trunk 22 { X 20, trunk 21 }07:20
poolielifeless: yeah me too but small steps07:20
vilahi all07:20
pooliei'd like to prototype some kind of dashboard07:21
davidstraussspiv: why would a single revision have children from two different branches?07:21
spivdavidstrauss: and expanded out one more level would be trunk 22 { trunk 21 { trunk 20 }, X 20 { X 19, trunk 21 } }07:21
davidstraussspiv: I mean, direct childred07:21
spivdavidstrauss: that's what a merge is07:21
davidstraussspiv: A merge pulls in revisions from one other branch07:21
spivdavidstrauss: also, "parent", not "children", unless you're asking a different question to what I think you are?07:22
davidstraussspiv: which may have children from other branches still07:22
poolielifeless: i guess overall the thing is that all the data is there, but the tools for querying it are not so great07:22
pooliefor something as simple as 'how many bugs are open in bzr' you need to iterate them07:22
pooliewhich is the opposite of what you want07:22
davidstraussspiv: but if i merge from another branch and commit as rev 22, revision 22 should only have direct child revisions from one other branch07:23
lifelesspoolie: meep, theres no __len__ on search results?07:23
spivdavidstrauss: it will have two parents07:23
spivdavidstrauss: and no children (yet)07:23
davidstraussspiv: so, the indented revisions below a merge revision in log are *parents*?07:23
lifelesspoolie: the API folk have expressed a strong desire to be told about issues07:24
spivdavidstrauss: those parents will be the previous tip of the branch you just committed in, plus the revision you merged in from the other branch.07:24
spivdavidstrauss: have you seen "bzr viz" or "bzr qlog"?07:24
RenatoSilva trunk 22 { X 20, trunk 21 }?07:24
davidstraussspiv: haven't used any gui tools07:24
spivdavidstrauss: the history is a DAG, and those tools do a good job of visualising it07:24
spivdavidstrauss: "bzr log" makes an attempt to represent some the structure of that DAG in plain ascii, which is inevitably a bit hard in complex cases :)07:25
RenatoSilvaspiv: I'll jsut keep X updated by merging trunk into it regularly, then when I'm done I'll merge X into trunk, and then see what happens in log/qlog :)07:25
spivdavidstrauss: if you pass --show-ids to log it will explicitly give the "parent:" links for each revision.07:26
spivRenatoSilva: good idea :)07:26
davidstraussspiv: ok, so let me rephrase my previous statement. "rev 22, which has parents {X's 18, 19, 20}. Also, X's 20 has parents {trunk's 18-21}.07:26
Peng_A revision only has 1-2 parents. But its parents have their parents, and on up the chain.07:27
davidstraussspiv: I still don't see how a revision could have parent revisions other than (1) in the same branch and (2) in one other branch07:27
spivdavidstrauss: "rev 22, which has parents {trunk 21, X 20}."07:27
lifelessPeng_: N parents07:27
Peng_(Not that it has to be restricted to a simple chain.)07:27
lifelessPeng_: hg has the 2 thing07:27
davidstraussspiv: Is rev 22 in X?07:27
Peng_lifeless: Oh, I thought bzr did too.07:27
spivdavidstrauss: "and consequently some of its ancestors are X 19, X 18, etc."07:27
Peng_Bazaar supports octopus merges?07:27
spivPeng_: yes07:27
lifelessPeng_: nope, 0 through to 'overflow a 4K b+Tree zlib page'07:27
lifelessPeng_: which is 'many'07:27
RenatoSilvadavidstrauss: this stuff is really ahrd to understand :)07:28
davidstraussRenatoSilva: Is rev 22 on branch X?07:28
Peng_lifeless: I hope that doesn't mean there will be some obscure index exception instead of a simple WhatTheHellAreYouDoingError.07:28
Peng_"bzr merge" will let you do it?07:29
lifelessPeng_: it will except on commit; and yes bzr  merge will let you do it - --force07:29
RenatoSilvadavidstrauss: I mean the whole subject07:29
davidstraussGiven that rev 22 has parents X:22 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct?07:29
RenatoSilvadavidstrauss: I can't see it as anything different from the weird rev 22 { X 18, 19, 20 { trunk 18-21 }  }07:29
davidstraussI meant "Given that rev 22 has parents X:20 and trunk:21 (according to spiv), it should follow that rev 22 is either on branch X or trunk, correct?"07:29
RenatoSilvadavidstrauss: I'll just try to do it in pratice and see what happens07:30
Peng_lifeless: Cool. I always figured --force would lose the other revision information or something, like with a cherrypick.07:30
spivdavidstrauss: yes, I'm talking about the example where X is merged into trunk07:31
spivdavidstrauss: e.g. "cd trunk; bzr merge path/to/X; bzr ci"07:32
davidstraussspiv: OK, this suddenly makes a bunch more sense.07:32
davidstraussspiv: I was assuming rev 22 was on yet another branch07:32
spivWhich AIUI was the example under discussion07:32
spivBut I might be wrong :)07:32
spivdavidstrauss: phew :)07:32
davidstraussspiv: and that's why i couldn't understand how it could have parents on two other branches07:32
lifelessspiv: it was trunk to X07:33
spivlifeless: hmm, skimming scrollback, I see both07:35
spivlifeless: the most proximate to where I started clarifying notation was X to trunk, though :P07:36
lifelessspiv: no its not :)07:36
davidstraussIt seems more likely that it's X->trunk, given that one of the parents is rev 21 on trunk.07:36
lifelessspiv: :08 RenatoSilva asked, 5 lines later or so you said you didn't get the notation :)07:36
davidstrauss(And knowing that the new revision is 22)07:36
poolielifeless: https://edge.launchpad.net/hydrazine07:37
pooliebarely anything there07:37
lifelessa foaming agent huh?07:37
davidstraussIf it were trunk->X, the new revision (22) would have to have rev 21 on X as a parent07:37
lifelessby definition, yes.07:38
lifelessbranch contents are recursively defined07:38
lifelessrev 21 is the first parent of rev 2207:38
RenatoSilvaso it really is trunk's 22 { X's 18, 19 and 20 { trunk's 18, 19 } }  ?07:39
poolielifeless: 'dangerously unstable'... 'used in various rocket fuels'07:39
poolie'  These reactions are extremely exothermic (the catalyst chamber can reach 800 °C in a matter of milliseconds,[22]) and they produce large volumes of hot gas from a small volume of liquid hydrazine,[23] making it a fairly efficient thruster propellant '07:40
pooliei aspire to making a fairly efficient propellant07:41
pooliewe shall see07:41
davidstraussWhen is the current "edge" version of LP going stable?07:41
poolie3.0 is targeted for the end of this week07:41
poolieand it'll run bzr 2.0.0 to07:42
spivlifeless: yes, I see :08, but :11 is more proximate to me :P07:42
davidstrausspoolie: Is there a comprehensive listing of changes?07:43
pooliein lp? or in bzr?07:43
davidstrausspoolie: in lp07:43
pooliei don't know, sorry07:43
davidstrausspoolie: bzr 2.0 is pretty obvious with the changelogs07:43
pooliewell, the branch is public07:44
RenatoSilvawhat's the recommended comment when commiting a merge with a lp branch? "merge with lp:project" ?07:44
poolieRenatoSilva: i guess that's fine, but maybe say why07:45
davidstraussRenatoSilva: Given that the merge will always be directly on "lp:project," it would mean every merge commit would be identically explained.07:45
davidstraussRenatoSilva: It's best to list any bug or question that's related.07:45
RenatoSilvaalways be directly on "lproject," ?07:46
spivRenatoSilva: that's fine, or even "merge from trunk", although as poolie says you're probably doing the merge for a reason, so stating that reason in the commit message is a good idea.07:46
davidstraussRenatoSilva: "Merge changes from branch lp:~davidstrauss/pressflow/blah to fix LP #23424"07:46
ubottuLaunchpad bug 23424 in pango1.0 "Opentype Latin fonts poorly handled" [Medium,Fix released] https://launchpad.net/bugs/2342407:46
spivRenatoSilva: e.g. "Merge from blah to get bugfix for 1234"07:46
RenatoSilvadavidstrauss: the reason for merging is always the same: to keep up-to-date with trunk07:46
davidstraussRenatoSilva: Oh, you mean a merge from trunk into your feature branch07:47
davidstraussRenatoSilva: I was assuming this would be into trunk from a feature branch07:47
spivBut personally I've often done just "Merge from trunk", and left the rationale implicit (keeping up to date to minimise integration headaches)07:47
davidstraussYeah, it's not important to be too detailed when merging from trunk to keep a feature branch updated.07:48
davidstraussThe opposite direction is where the commit messages matter more than anywhere07:48
spivIf I'm merging from an unusual source or for an unusual reason I would say why, though.07:48
RenatoSilvadavidstrauss: yes, X into trunk would be "merge with lp:~user/project/subject", and I think bug numbers and explanations they're all in the branch, the problem is if it is deleted after merging07:49
RenatoSilvadoesn't source branch go automatically into commit metadata?07:49
davidstraussRenatoSilva: Merged revisions retain all data post-merge07:49
RenatoSilvadavidstrauss: Merged revisions retain all data post-merge?07:50
RenatoSilvaAren't I repeating info when typing branch name in commit?07:50
spivRenatoSilva: merge copies all the revisions that are referenced (and not already present)07:50
Peng_I prefer commit messages like "AutoWidget 3.0 support (Some User, #12345)".07:50
Peng_I guess it would make sense to include the branch URL too, though.07:50
RenatoSilvaPeng_: doesn't it go into commit metadata?07:51
davidstraussRenatoSilva: The branch URL isn't the same as the branch short name07:51
RenatoSilvaok url is better07:51
spivRenatoSilva: (and recursively, so parents of parents of parents, etc, will be copied.  So if you merge a branch to trunk it is possible to later rebranch that old branch from trunk)07:51
RenatoSilvaif url is stored, then no need of even the word merge07:52
RenatoSilvayou just say "fix for problem x" or "new feature y", it doesn't matter whether it is a merge or regular revision07:52
spivRenatoSilva: basically, whatever works well for you :)07:53
RenatoSilvaI just think it's a bit weird having to put any message for just keeping up-to-date with trunk07:53
RenatoSilvaspiv: but I want to know if urls are stored or not :)07:53
spivRenatoSilva: No07:53
spivNot in the history.07:53
davidstraussRenatoSilva: you might prefer rebase07:54
RenatoSilvaspiv: so it says it is a merge, but don't say a merge with what?07:54
davidstraussRenatoSilva: I personally hate rebase07:54
RenatoSilvawhat's rebase?07:54
davidstraussRenatoSilva: Please use google07:54
spivRenatoSilva: the history has a full copy of all the revisions from the source branch that you merged from.07:54
spivdavidstrauss: hmm, I don't see how rebase would help here07:55
RenatoSilvaspiv: i know07:55
RenatoSilvaspiv: but you don't know from where they came from if you don't have urls07:55
davidstraussspiv: It would eliminate RenatoSilva having to write commit messages for merging from trunk07:55
spivTrue, but why do you need where they came from if you have the commits themselves already?07:55
davidstraussRenatoSilva: It's literally impossible for bzr to guess the canonical URL for a branch at merge time07:56
spivI.e. what information does "where they came from" tell you that can't already get from the commit messages, authors, etc in the actual commits?07:56
spivdavidstrauss: oh, I see.  I think that would be the tail wagging the dog, personally.07:56
davidstraussspiv: Indeed.07:57
RenatoSilvaI'm thinking of a workaround: merge X into trunk locally, delete lp's X, push local trunk as X. How about it :)07:57
davidstraussSo, if Launchpad is launching with bzr 2.0 this week, does that mean bzr 2.0 is going stable, too?07:58
davidstraussRenatoSilva: How does that change anything?07:58
RenatoSilvadavidstrauss: humm, true :(07:58
lifeless2.0 is already stable07:59
RenatoSilvaI just think up-to-date merging is not natural07:59
davidstraussRenatoSilva: Rather, it would just create a very confusing history.07:59
davidstraussRenatoSilva: What do you consider a natural alternative?07:59
lifelessRenatoSilva: you don't need to delete lp's x; just push over it07:59
lifelessRenatoSilva: I think you could do your workaround; it will look very similar, but you won't be able to as easily tell where you merged trunk, which means you won't know why a bug was introduced.08:00
RenatoSilvadavidstrauss: well s/merge X into trunk/bzr send X > trunk, how about it08:00
RenatoSilvaa natural way is one just like I'm cerating X NOW08:01
davidstrausslifeless: I disagree. There's a big problem with the proposed workaround: every time he updates from trunk, the commit history for his feature branch gets buried in the parents of a merge revision.08:01
RenatoSilvaand applying the changes, that before were revs 18, 19 and now would be palin revs 22, 2308:01
davidstrausslifeless: It creates a history with a depth at least as many parents deep as the number of merges with trunk08:02
RenatoSilvaImagine I can get X and extract the changes on raw diffs08:02
RenatoSilvathen I bzr branch trunk and manually apply the diffs08:02
RenatoSilvaand commit08:03
RenatoSilvajust like I'm cerating X today08:03
davidstraussRenatoSilva: "bzr send" is just a tool for packaging merge data08:03
RenatoSilvadavidstrauss: well it would not work as the branches have diverged08:03
davidstraussRenatoSilva: What does "send" have to do with the branches diverging?08:03
RenatoSilvadavidstrauss: I'd pry to bzr pull md.diff08:03
davidstraussRenatoSilva: I think you should look at http://bazaar-vcs.org/Rebase before trying such an ill-advised workflow08:04
davidstraussRenatoSilva: Taking a fresh branch, applying the old diff, and committing is just a bad approximation of rebase08:05
RenatoSilvaok thanks08:05
RenatoSilvaas I have a commit prompt in my front, I'll just type merge with trunk by now :)08:06
davidstraussRenatoSilva: Rebase treats updating a feature branch from trunk as fundamentally different from merging08:06
davidstraussRenatoSilva: I advise against using the language "with" for bzr merges08:06
RenatoSilvamerge from trunk?08:07
davidstraussRenatoSilva: In Bazaar, merges are directional. Branch A can be merged into B, or B into A, but there is no single operation that does both08:07
davidstraussRenatoSilva: Either "merge from trunk" or "merge trunk into _____"08:07
RenatoSilvamerge trunk into here08:07
davidstraussRenatoSilva: "From" is generally best because the "to" is obvious08:07
davidstraussRenatoSilva: "To" is always the current branch08:08
RenatoSilvawith is obvious too08:08
RenatoSilvamerge with trunk cannot mean merge this into trunk08:08
davidstraussRenatoSilva: Not really. Once your revisions get merged back into trunk, the "merge with trunk" commit messages may be a bit ambiguous08:08
RenatoSilvabecause the comment would be in trunk, not in this branch :)08:08
RenatoSilvaok ok, not that bad to be clearer anyway08:09
davidstraussRenatoSilva: Remember that every commit you create on the feature branch will be browsable on the trunk after the feature branch is merged back into trunk.08:10
RenatoSilva"Merging trunk changes"08:11
RenatoSilvahow about it08:11
RenatoSilvaor "Trunk changes merge"08:12
davidstraussRenatoSilva: "Merge from trunk" is my usual one08:12
RenatoSilvaMaybe rebase or something similar could be in bzr as default08:12
davidstraussRenatoSilva: "changes" is redundant. All revisions and merges are of "changes"08:12
davidstraussRenatoSilva: rebase is distributed with most bzr installs08:13
RenatoSilvaI don't like 'from'08:13
davidstraussRenatoSilva: Is there a reason why?08:13
RenatoSilvawhy don't you like rebase?08:13
davidstraussRenatoSilva: http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar08:14
RenatoSilvaMerging trunk --> trunk changes into here or here's changes into trunk??? Merging trunk changes ----> oh, trunk changes were merged (obviously, into here)08:14
=== weigon_ is now known as weigon
RenatoSilvabookmarked your link, thanks08:17
* vila . o 0 (God bless people that fix loom test failures :-)08:18
davidstraussvila: Is Looms being actively developed?08:19
viladavidstrauss: supported rather than developed, but it's here to stay under one form or another if that's what you care about08:21
davidstraussvila: What's the preferred option, that other one that works among multiple branches?08:21
viladavidstrauss: I use loom or regular branches myself, but some people seem more at ease with bzr-pipeline (if that's what you're referring to :)08:22
viladavidstrauss: I don't have an opinion on their respective merits since I use only loom but I heard that pipeline were fitting its users needs08:23
viladavidstrauss: both are work in progress AIUI08:23
davidstraussPipeline looks like a crappy copy of the git branching interface08:24
RenatoSilvahttp://img24.imageshack.us/img24/1857/imagemxv.png ---> WEIRD !08:24
davidstraussRenatoSilva: Looks normal to me08:25
RenatoSilvadavidstrauss: hard to understand, I mean08:25
davidstraussRenatoSilva: Granted, I've never used this application before, but this is what I see:08:26
RenatoSilvaabsolutely crazzy actually08:26
davidstrauss(1) upserprefs is branched from trunk08:26
davidstraussat 1708:26
davidstrauss(2a) Revs 18-21 get made on trunk08:26
davidstrauss(2b) The theme prefs work gets committed to userprefs.08:26
davidstrauss(3) Merge from trunk -> userprefs08:27
davidstrauss(4) Merge from userprefs -> trunk08:27
davidstraussRenatoSilva: right?08:27
spivdavidstrauss: right :)08:27
RenatoSilvadavidstrauss: humm :)08:27
RenatoSilvahow about the numbers 17.1.1 and 17.1.208:27
davidstraussIt's unclear (and irrelevant) whether 2a or 2b happened before one another08:27
davidstraussRenatoSilva: The first number means you merged from a branch that was originally branched at revision 17.08:28
spivRenatoSilva: those are just the revision number's bzr assigns those revisions; http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers08:29
RenatoSilvaok I just mean weird numbers08:29
davidstraussRenatoSilva: the revision numbers are unique for all numbers on the trunk08:30
davidstraussRenatoSilva: unique and stable08:30
RenatoSilvaI'd use 22.1 and 22.2 instead of 17.1.1 and 17.1.208:30
RenatoSilvawhat does the red lines and circles mean?08:31
davidstraussRenatoSilva: The red line is the merge into trunk from the feature branch08:31
davidstraussRenatoSilva: The red circles are unique revisions on the feature branch08:32
spivRenatoSilva: I think the colours are just to help you associate revisions from the same branch08:32
spivRenatoSilva: so qlog has arbitrarily chosen grey/black for trunk and red for userprefs, I think.08:32
RenatoSilvamaybe I get those numbers better later08:33
spivRenatoSilva: you can ignore the numbers if you like, you probably don't need to use them.08:33
davidstraussRenatoSilva: If we numbered like 22.1 and 22.2, the numbering wouldn't actually provide any useful data about the source of the revisions08:33
davidstraussRenatoSilva: spiv is right; you can just treat the numbers as opaque strings08:34
spivdavidstrauss: (actually, I usually am more interested in when revisions got merged than when they were branched, but that's another discussion...)08:34
RenatoSilvaok guys08:34
davidstraussspiv: But it's obvious where revisions got merged in the bzr log --include-merges08:34
spiv(and either way, a graphical tool like qlog is probably a nicer solution than interpreting dotted revnos)08:34
spivdavidstrauss: ah, but that presumes I know when the revision was merged ;)08:35
spivdavidstrauss: or requires me to log all of history08:35
davidstraussspiv: You mean by time?08:35
davidstraussspiv: Are you trying to answer, "Given revision ID X (and no other data), I want to know where it was merged into my current branch."08:36
spivdavidstrauss: yes08:37
davidstraussspiv: There's no way to look that up with the log tool?08:37
spivdavidstrauss: qlog or similiar does a good job of it (I haven't looked recently, so pardon my lack of precision), but not in core "bzr log", no :(08:38
spivActually, qannotate is probably what I'm thinking of.08:39
RenatoSilvawhat about bzr log --include-merges ?08:39
spivThe use case is usually "look at annotations, see a line of interest, and wonder a) what the original commit that introduced that line was, and b) when it landed in this branch"08:39
spivAnd qannotate handles that very very nicely, IIRC.08:40
spivRenatoSilva: that will show all revisions, including merges, but I'd rather not have to grep all of history if I can help it :)08:41
davidstraussspiv: Actually, you can. It's just two steps.08:43
davidstraussspiv: bzr log -rX --show-ids08:43
davidstraussspiv: bzr log -rrevid:[parent-from-last-command-results]08:44
davidstraussspiv: sorry08:44
davidstraussspiv: that's just the source08:44
spivdavidstrauss: right :)08:44
spivdavidstrauss: given that qannotate exists and works so well I'm probably not going to scratch this itch any time soon, but it probably wouldn't be so hard to extend log somehow to handle this.08:45
spivPossibly with mainline:REV revisionspec or something.08:46
davidstraussspiv: Looking into the bzr architecture, it appears that there's no way to directly determine the children of a revision.08:46
davidstraussspiv: It has to be constructed by iterating through the mainline08:46
spivYes, graph-walking is required.  But that's how bzr determines the x.y.z revno anyway.08:46
davidstraussspiv: How does the second number of a merged revision get set if I branch from A->B, then B->C, and then merge C->A?08:47
vilalifeless: bug #433843 and associated fix in lp:~vila/qbzr/433843-fix-isolation-breaks08:47
ubottuLaunchpad bug 433843 in qbzr "test failures trying to escape isolation" [Undecided,Fix committed] https://launchpad.net/bugs/43384308:47
lifelessvila: is there a merge proposal?08:48
davidstraussspiv: s/second number of a merged revision/second number of the merged revisions/08:48
vilalifeless: permit_dir('/') sounds like the easiest way to fix it and not being that heretic08:48
lifelessvila: I'll need to look08:48
vilalifeless: it's in qbzr just as sec08:48
davidstraussspiv: Oh, bzr must just assign that number at merge time08:48
spivdavidstrauss: So multiple levels of merge between mainline and that rev, you mean?08:48
davidstraussspiv: nevermind08:48
spivok :)08:48
vilalifeless: https://code.edge.launchpad.net/~vila/qbzr/433843-fix-isolation-breaks/+merge/1214808:49
davidstraussspiv: I was trying to figure out how the second number (which is the ordinal of branches off the revision in the first number) was assigned when branching is read-only and transitive08:49
davidstraussspiv: But it's clear there's no way that could happen until merge-time08:49
spivdavidstrauss: right08:51
ngnpI want to merge 2 websites codebase. Yesterday I upgraded 1 website. Added a 'before upgrade'. Now I want to start working on site 2 with that tag.09:00
ngnpCan I continue working in the same directory? I still not understand bzr branching :(09:00
ngnps/Added a/Added a tag/09:01
RenatoSilvathanks everybody09:02
davidstraussngnp: Don't your sites have different directories?09:02
ngnpdavidstrauss: partly ... but the main code is the same09:03
davidstraussngnp: you can branch from the tag09:03
ngnpin the same working dir?09:03
davidstraussngnp: i would use a different dir09:03
ngnpotherwise I have to reconfigure apache :(09:04
ngnpdavidstrauss: I guessed I had to. I hoped for a 'switch to' tag09:04
davidstraussngnp: you can revert to a tag09:05
ngnpand then merge later with current .bzr or through a push09:05
davidstraussngnp: I'm still not clear on your workflow09:07
ngnpdavidstrauss: me neither ... with eclipse/svn i'm used to 'switch to' and then continue working on that older/newer version. Code stays in same dir. But that is with central repo. Now I have a local. So I guess I need more experience with bzr ...09:10
ngnpTnx for your time :)09:10
davidstraussngnp: you can't switch to tags in bzr09:10
davidstraussngnp: tags are merely aliases for revision numbers09:10
ngnpic ... so I have to "bzr pull -r 7" then upgrade site 2, then merge with site 1?09:12
davidstraussngnp: I still don't understand your upgrade workflow, but I have to head off.09:13
davidstraussngnp: Sorry :-/09:13
ngnpnp .. cy09:13
trondnwhy do bzr status show unknown filenames from the root (if my cwd isn't root of the repository), and if I try to add them it only tries to do so relative from my cwd???09:21
bialixtrondn: this is old bug09:24
trondnbialix: ah.. ok.. just got bitten by it...09:24
* igc dinner09:33
igcbialix: 429911 has some further info now -bbl09:34
bialixigc: hi09:35
bialixubottu, say me please URL for bug 42991109:36
ubottuLaunchpad bug 429911 in bzr-explorer "BZR > Explorer > UnicodeDecodeError" [High,New] https://launchpad.net/bugs/42991109:36
ubottuError: I am only a bot, please don't think I'm intelligent :)09:36
lifelesstrondn: its a mismatch09:36
bialixgood ubottu, take a cookie09:36
lifelesstrondn: there is a desire to have commands report paths from the root; but its [fairly clear to me] that this doesn't work well with paths users type in from their shell09:36
lifelesstrondn: and commands like add work from that basis09:36
bialixigc: re that bug, we seems to get mbcs encoding path to wordpad.exe. we need to cast it to unicode.09:37
trondnlifeless: I would expect that I could use the output from one command as the input to the next one without having to change directory.. That said, its not that big of a problem :)09:38
lifelesstrondn: me too!09:38
lifelessvila: sorry, was on a call09:44
vilalifeless: no worries09:44
lifelessvila: MemoryTransport09:45
lifelessvila: someone may have a branch at /09:45
bialixvila: check isolation is bad idea09:45
lifelessbialix: its a very good idea; its telling you about latent bugs in your test suite09:45
vilalifeless: in theory yes, that's why I restricted the permit_dir('/') to very very narrow tests09:46
lifelessvila: they look like they should cope with MemoryTransport, no ?09:46
vilathey all want to check a '/not/existant/branch'09:46
bialixaaron insists that MemoryTransport is not very well09:47
vilabialix: MemoryTransport is not *yet* very well, it doesn't mean we can't take it there09:47
bialixvila: does your patch compatible with bzr 2.0?09:47
lifelessbialix: he's asserted that MemoryTree is a problem; its not very complete which I agree with, but PreviewTree writes to disk so is slow.09:47
bialixvila: or more precisely: with 1.17 API?09:48
lifelessMemoryTransport is fully compatible with Transport, I'm not aware of any issues with it.09:48
vilabialix: does your test suite pass ?09:48
bialixvila: I'm using 1.18.109:48
lifelessbialix: that patch won't be comaptible with < 2.109:48
bialixvila: test suite pass for me09:49
bialixvila: w/o your patch09:49
vilabialix: feel free to delay landing that patch, I'm not going to play tricks to guarantee API backward compatibility for potentially borken tests...09:49
bialixyou can make self.permit_dir optional09:50
NET||abusehey folks,, looking for an article on using bzr in deployment of web site code.10:17
NET||abusei saw an article before where you setup a bare repository on your webserver, then you setup some kind of hook which exports the code straight to the site working directories on pushing up from your local branch.10:18
NET||abusedoes anyone know of this technique or know where the article might live.. google isn't getting me there today.10:18
KinnisonPersonally I use a cron job10:19
Kinnisonbecause my site needs an amount of 'building' before it can go live.10:20
KinnisonMy cronjob pulls, if any updates happened, it runs 'make check' and then rsyncs the content10:20
NET||abusethe site i'm working on doesn't need any building like that, just need to export 2 tree paths to locations in the website accounts directories.10:31
NET||abusejust looking for a way to push it up to the webserver10:31
vilabialix: I'm not part of qbzr-devs 8-) I can't supersede my own submission :D10:37
vilalifeless: nice suggestion, works like a charm10:38
vilalifeless: (MemoryServer is needed instead of MemoryTransport of course, but that was semi-obvious ;-)10:39
vilabialix: bah forget my last remark, the UI has changed again and I thought I couldn't resubmit where in fact hte button has just been moved10:40
fullermdOh good.  I was just thinking, "Gee, bzr _seems_ like a decent project, but where are the long license discussions?"10:47
bialixvila: so what should I do?10:47
vilafullermd: bzr is a GNU project :-D10:47
rustyHi all...  Can I just double-check: .bzrignore files must be in top level of project, right? And there's no comment syntax?10:47
Peng_rusty: 1.) Right. 2.) Comments start with #10:48
rustyPeng_: ah, thanks... I couldn't find any documentation on that point.10:48
vilabialix: well, I applied to join the team, feel free to approve me :-D As for the patch, I think I addressed all concerns raised by lifeless and you, so again, feel free to approve and merge :-P10:48
rustyPeng_: does \ escape # then?10:48
Peng_rusty: Noo idea.10:49
spivfullermd: haha10:49
Peng_rusty: Try it and see! :D10:49
bialixvila: so I should feel free as twice as usual?10:49
lifelessrusty: hi10:49
fullermdNow all it needs to do is read email, and it'll be a Real Opensource Project.10:49
spivrusty: I suppose [#] would work too...10:49
lifelessrusty: you pung me about subunit; did you get my replies ?10:49
rustylifeless: hi!  Just back on the .vcignore tradmill...10:49
vilabialix: yeah, welcome to free software world :D10:49
bialixtriple free10:49
rustylifeless: yep!  But then I went away for 3 weeks, and the draft sitting there when I got back today seemed stale :)_10:50
lifelessrusty: I'm doing a subunit talk @ LCA10:50
lifelessrusty: so the more adoption between now and then the better :)10:50
bialixwe decided to make part of our new project free (LGPL)10:50
rustylifeless: I've pretty much decided to go with libtap for the moment, but the API could be easily changed to output subunit directly (rather than via tap2subunit)10:50
spivrusty: in fact, I see that the default ~/.bazaar/ignore uses [#] to escape a rule :)10:50
lifelessrusty: whats the usecase/situation?10:51
bialixvila: if you join qbzr-dev you'll get all bugmails10:51
rustyspiv, bialix: \# works too.10:51
rustyOops, I mean Peng_10:52
vilabialix: ha, right :-/10:52
Peng_rusty: Cool. (You mean it does what you want, right?)10:52
rustyPeng_: I'm compiling a table of the different VC systems ignore semantics, that's all!10:52
vilabialix: there should an option somewhere that allow me to unsubscribe to these mails, otherwise, I'll filter them, anyway, I think I better join anyway10:54
lifelessrusty: so, tell me more about where you're choosing between tap/subunit10:55
lifelessrusty: or I'll have to supply you with beer and ask you @ LCA10:55
bialixvila: ok, be good boy and don't commit wild code then.11:11
bialixvila: approved, welcome to the club11:12
vilabialix: :-D11:12
rustylifeless: because I maintain libtap? :)11:12
lifelessrusty: :P11:12
lifelessrusty: then I should talk to you about how subunit is an improvement over tap :)11:13
lifelessrusty: however, you said something about samba?11:13
rustylifeless: naah, line-at-a-time rules :)11:13
SamB_XPand here I thought tap was to do with ethernet ...11:13
lifelessrusty: shame that it can't detect unfimished11:14
rustylifeless: well, it can if you have a plan...11:14
SamB_XPrusty: you mean, like a plan to cook and eat you ?11:14
lifelessrusty: I know :> [tap2subunit handles that]11:15
rustylifeless: yes, I want to put some unit test infrastructure into the samba tree.  They already use subunit, so makes sense to aim for that.11:15
lifelessrusty: they have a thing called libtortue11:15
lifelesshave you found that?11:15
rustylifeless: yeah, but it confuses torture testing and performance testing with correctness and unit testing.11:16
lifelessjelmer: ^11:16
rustylifeless: I really want just unit tests, ie. "hey, I really screwed this up" :)11:16
lifelessrusty: so I think a good reason to use libsubunit for stuff in the samba tree is because it's easier ;)11:17
lifelessrusty: tap2subunit isn't ugly, but its not brilliant either. Much better to start with the same protocol, unless you have some external code you're just exposing.11:17
rustylifeless: my tdb and talloc tests are already using libtap tho :)11:17
rusty(CCAN went for libtap)11:18
lifelessare you at all interested in being able to drop maintenance of libtap ?11:18
rustylifeless: TBH I think subunit is a YA project.  Tap is nice and browsable, and simple.11:19
lifelessSamB_XP: http://en.wikipedia.org/wiki/Test_Anything_Protocol11:19
SamB_XPrusty: young adult ?11:19
lifelessSamB_XP: yet another11:19
NET||abuseyarg,, keyserver down?11:20
lifelessSamB_XP: pejorative sometimes, sometimes adopted such as 'yaml' - yet another meta language11:20
SamB_XPyeah, I've seen many programs whose names start with "ya" for that reason11:20
rustylifeless: my main issue with TAP is lack of nesting, which is finally being fixed...11:21
lifelessrusty: I disagree rather strongly there; taps simpleness pushes burdens onto the programmer/editor; I can go into some detail of the things it inhibits another time11:21
rustylifeless: In my limited experience it has been sufficient.  I don't like complex tests :)11:22
lifelessrusty: this isn't about the test though - its about what you do with them11:23
SamB_XPrusty: it's not so much complex tests as nested test suites, I think11:23
lifelessrusty: taps not introspectable; you can't run - or even sensibly approach the problem - of running just a single thing from tap in an edit-test cycle, as a for-instance.11:24
rustySamB_XP: yes, I agree.  Which is why I'm happy about the nested TAP implementation.  I have exactly this issue with ccanlint, in fact.11:24
lifelessrusty: anyhow, you're happy with tap - great. Let me know of any bugs or glitches you have with tap2subunit and I'll fix em.11:25
rustylifeless: unit tests should be so fast you don't need to :)11:25
SamB_XPrusty: yeah right!11:25
lifelessrusty: ack; see my blog recently ;)11:25
SamB_XPsome of us use finite-clocked computers11:26
lifelessrusty: but, you shouldn't have to change test _protocol_ to work with integration tests, acceptance tests, and so forth.11:26
SamB_XPhave to admit bzr does a pretty good job of using the same framework for acceptance-type tests as for plain-old unit tests ;-)11:27
lifelesswhen you change protocols you change toolchains; unless one toolchain is a strict superset and can read the other protocol11:28
rustylifeless: it's not clear why that universal protocol shouldn't be TAP tho!11:28
SamB_XPrusty: well, not having enough features might do it ;-)11:29
SamB_XPlifeless: maybe you should write a blog entry about it ;-)11:29
lifelessSamB_XP: I have a 'real testing needs XXX' list to finish; my most recent post to the TIP list was one of the items on that list.11:30
SamB_XPtip list?11:30
lifelessSamB_XP: when I get those items checked off, I'll feel confident going 20 rounds vs TAP anyday :)11:30
lifelessSamB_XP: testing-in-python@lists.idyll.org11:30
jelmerrusty: I think you mean smbtorture11:33
lifelessrusty: there are a bunch of reasons that make it clear to me ;). it can't tell the different between streaming & trailing plans - unless its told at the front :P. fixtures aren't addressable; the model it encodes isn't comaptible with xUnit(arguably _way_ more successful than TAP), it can't attach [for transport] test artifacts (neither can subunit, in progress), it can't provide progress [unless it has an up front plan]11:33
jelmerrusty: libtorture is just a unittest framework11:33
lifelesshmm, did that cut off ?11:33
jelmerhi, btw :-)11:34
lifelesshi jelmer :)11:34
lifelessjelmer: where did that run-on paragraph end for you jelmer ?11:34
jelmer"front plan]11:35
lifelessoh cool11:35
rustyjelmer: hi :)  Yes, smbtorture conflates a lot of different tests.  I'm mainly concerned about the lib/ dir; it'd be nice to have good unit tests for stuff in there.11:35
lifelessrusty: jelmer wrote a *separate* think 'libtorture' - its not smbtorture11:36
jelmerlifeless: some things in smbtorture use libtorture though11:36
lifelesssure, but rusty is seeking pure unittesting, which is what I thought, and you're confirming, libtorture is11:37
jelmerlifeless: initially we just had very big functions that would return 0 or 1 depending on whether all of the hundreds of subtests they ran succeeded11:37
jelmerlifeless: right11:37
jelmerrusty: there are some things that do have tests11:38
jelmerrusty: in particular for some of the functions in lib/util/ we have basic unit tests11:38
jelmerrusty: see lib/util/tests11:39
lifelessrusty: there's more, but its not really a 'quick over IRC' discussion, so I'm inclined to shelve it until either I get time to write a serious blog post on it (and endure any flames :P) or we're face to face and I can show you stuff11:39
lifelessrusty: you might like to watch the SLUG talk I did a couple of months back; it was a 'oh we need a speaker urgently' deal, but not bad all the same11:40
rustylifeless: sure... I've been happy with tap.  But I *always* use a plan.  The arbitrary numbering of tests, rather than being explicitly labelled: well, you should see what libtorture does :)11:41
lifelessrusty: I'm happy for users to make their life as hard as they want :)11:43
rustylifeless: ccan uses a simple system where independent test cases go in separate source files.  So ideally only dependent tests are in a single file.  It works quite well for isolating tests (though a gdb helper to stop on the first fail would be a win).11:44
rustylifeless: for CCAN, I want any idiot to be able to write tests.  libtap has the benefit of simplicity.  libtorture starts to push the curve, *and* you don't get "addressable fixtures" (if that means what I think it means?)11:47
jelmerrusty: libtorture does give you all that's required for addressable fixtures (if I am guessing right what they are)11:47
jelmerrusty: addressable fixtures just aren't implemented yet11:48
lifelessan addressable fixture is just naming a single test11:49
lifelessrusty: I'm not sure I want idiots writing C code :) but I agree with the desire for simplicity11:51
rustylifeless: right,that's what I figured.  tap uses numbers, which is a movable feast unless you have the source in front of you.11:51
rustylifeless: (and even then, figuring out the 113th test can be nontrivial)11:51
rustylifeless: but in libtap the test name (if using "ok1" which is the simplest) is the code, which is the same as libtorture's torture_assert().11:53
lifelessrusty: interesting11:54
lifelessrusty: have you seen check ?11:54
lifelessrusty: you'll probably hate it, because it needs some boilerplate to insert it into a project, but I'm curious :)11:55
rustylifeless: no?11:55
lifeless(or apt-get install check)11:56
lifelessits an xUnitish C unittesting library11:56
lifelessforks() before fixtures11:56
lifelesssupports some half decent higher order assertions - not brilliant though11:56
rustylifeless: this is *not* helping me get through my email backlog!!12:00
lifelessrusty: phfhtaw12:02
Alcmene_Eer... Hello? :)12:21
Alcmene_Is there anyone here available to give a little bit of help for a problem with bzr on OS X, whose cause is an upgrade from 1.13 to 1.17?12:22
PengI probably can't help, but I'm curious what your problem is.12:22
Alcmene_well, mostly the fact that I get the following notice every time I use bazaar :12:23
Alcmene_"Key 'foreign-mapping-upgrade' already registered"12:23
Alcmene_Unable to load plugin 'rebase' from '/Library/Python/2.5/site-packages/bzrlib/plugins'12:23
Alcmene_fact is, the rebase plugin exists in the given directory12:23
jelmerAlcmene_: you have incompatible versions of svn and rebase12:23
Alcmene_so, the problem is with svn and not bzr ?12:24
Alcmene_anyway, I've been living with this notice for two weeks, so it's not the main problem12:24
Alcmene_the big one happened when I tried to use the "push" command12:25
Alcmene_bzr: ERROR: The API for "<module 'bzrlib' from '/Library/Python/2.5/site-packages/bzrlib/__init__.pyc'>" is not compatible with "(1, 13, 0)". It supports versions "(1, 17, 0)" to "(1, 17, 0)".12:25
jelmerAlcmene_: with bzr-svn12:25
Alcmene_I therefore assume that the upgrade from 1.13 to 1.17 didn't go totally well, which I already suspected before12:25
Alcmene_unfortunately, I haven't found any way to uninstall bazaar completely12:26
Alcmene_since I haven't found a full list of all installed data12:26
Alcmene_jelmer: isn't the bzr-svn plugin packaged with the bzr isntaller itself? I don't understand why I should upgrade it on its own :s12:27
Peng_'bzr plugins -v' shows their paths.12:28
PengSo will the traceback in .bzr.log (use 'bzr version' to see where that's located).12:28
jelmerAlcmene_: I'm not saying you should upgrade bzr-svn necessarily, just that the versions of bzr-svn and bzr-rebase you have installed are incompatible with each other12:28
* Alcmene_ is checking the log12:30
Alcmene_jelmer: are you sure about that? Cause the log says "Plugin name svn already loaded", which is quite the same as "Key 'foreign-mapping-upgrade' already registered": makes me think that I have a plugin duplicate, one from 1.13, and one from 1.17. How does this sound to you?12:33
Alcmene_Furthermore, the "IncompatibleAPI" message I gave earlier says that (unless I misunderstand something) my bzrlib module expects bzr to be 1.17 and not 1.13... While my bzr _is_ 1.17!12:36
=== mrevell is now known as mrevell-lunch
fullermdNo, that's just unclarity of the message.  It means SOMETHING expects bzrlib 1.13 and got 1.17.12:38
Alcmene_fullermd: mmh, that's interesting. Thanks!12:39
Alcmene_Examinating the log, it seems that bzr-svn is called when trying to use "push"12:40
Alcmene_so I think we have spotted our guilty module12:40
Alcmene_however, if someone could tell me why the hell bazaar calls bzr-svn when pushing a bzr branch to an ftp server... :s12:40
jelmerAlcmene_: it's not called, but loaded nonetheless12:44
jelmer(all plugins are loaded when bzr is started)12:44
Alcmene_I agree, it's always loaded (that's the cause of the notice I get every time), but it is actually used when using push12:45
Alcmene_because it's only when using this command that svn-bzr outputs to the log12:46
Alcmene_...and only with it that I get an error and not just a warning12:46
jelmerAlcmene_: it might be trying to see if the remote location happens to contain a svn repo12:48
Alcmene_might be, yeah12:49
Alcmene_anyway, I have the trace now, so perhaps I'll take a look at it12:49
Alcmene_this IRC is logged and archives are publicly available, isn't it?12:49
Lo-lan-doHi all12:50
=== pwolanin is now known as pwolanin|afk
Lo-lan-doIs there a way to do a bzr push without remembering the address of the pushed-to branch?12:50
Alcmene_Hi Lo-lan-do12:51
=== doko_ is now known as doko
bob2Lo-lan-do: when you first push, bzr remembers that url and should use it in future if you just run 'bzr push'12:53
Lo-lan-dobob2: Yes, and I'd like to avoid that in some circumstances :-)12:53
Alcmene_bob2: he asks for the opposite ;)12:53
bob2Lo-lan-do: sorry, totally missed the '-out'12:54
Alcmene_Lo-lan-do: do you want to sometimes push to another server and have bzr remember the previous one instead?12:54
Alcmene_Or do you want it to not remember at all?12:54
Lo-lan-doAlcmene_: I want it to not remember at all.12:54
Lo-lan-doThe context is that I want to mirror a local repo into a remote one with pushes.12:54
Alcmene_and don't want bzr to push every time you commit ?12:55
Lo-lan-doSome of my local branches have push addresses memorised, which is fine.12:55
Lo-lan-doOthers don't, and then my mirror script will remember unwanted addresses.12:55
Lo-lan-doAlcmene_: No, this is a maintenance script I intend to run from time to time only.12:55
Lo-lan-do(I know about bound branches :-)12:56
Alcmene_Lo-lan-do: (couldn't know, had to try ;) )12:56
Alcmene_well, have you tried --no-remember?12:56
Alcmene_cause the help tells you about --strict and --remember12:57
Alcmene_but the --no-strict option exists, even though it is not listed12:57
Lo-lan-doGood to know, let me try that.12:57
Alcmene_perhaps have they implemented it too?12:57
Lo-lan-dopush --no-remember doesn't give an error message, but it still remembers the URL :-/12:58
Alcmene_from the doc:13:00
Alcmene_If there is no default push location set, the first push will set it. After that, you can omit the location to use the default. To change the default, use --remember. The value will only be saved if the remote location can be accessed.13:00
Alcmene_doesn't seem like they've thought that someone would _not_ want it to be remembered13:00
Lo-lan-doI'll just have to patch it :-)13:01
Lo-lan-doIn the meantime, I'll sed on the branch.conf13:01
Alcmene_(omission that I totally understand, BTW  ;) )13:01
Alcmene_Ok, so, just in case all of this is logged and someone happens to have the same problem as I had: the problem was an obsolete bzr-svn version13:24
Alcmene_I know, sounds obvious :(13:25
Lo-lan-dodiff size stuff?13:25
fullermdLo-lan-do: You can set the push loc in the branch.conf to an empty string, and then it won't be touched (except by --remember)...13:48
Lo-lan-dofullermd: But then I lose the automatic remembering next time I do a manual push.13:54
Lo-lan-doBut thanks for the idea :-)13:55
Alcmene_well, you could add the --remember option to the default ones in the conf13:56
Alcmene_or you could also, with your script, save the previous location, do the push, and re-write the previous location back13:56
jelmerhi Lo-lan-do13:57
Lo-lan-doHi jelmer13:59
Lo-lan-doAlcmene_: I think it might be simpler to just implement a working --no-remember option :-)14:00
Takhello jelmer14:01
Alcmene_Lo-lan-do: might be, yeah ;)14:04
jelmerhi Tak14:06
jelmerTak: Feel free to merge your branch into lp:monodevelop-bzr - I've approved it14:07
Takoh, ok14:08
TakI'm not overly familiar with how that works on launchpad :-)14:08
Takdo you have any thoughts on how "Review Changes" should act when there are pending merges?14:08
jelmerTak: it should probably list the pending merges somewhere14:09
Takhmm...I don't have a ton of control over how that works without completely overriding/rewriting the UI for that panel14:11
TakI suppose I could try creating a dummy diffset with the merges grouped together14:13
Lo-lan-doCan bzr reconcile fix "inconsistent parents" errors?14:18
Lo-lan-doThanks, I'll try that.14:19
Lo-lan-doI'm getting a KnitCorrupt error when pushing to a branch that has them.  Hopefully a reconcile will allow me to push again.14:20
=== mrevell-lunch is now known as mrevell
fullermdLo-lan-do: I doubt the two are related.15:31
Lo-lan-dofullermd: Indeed, the push failed.  I'm trying to start afresh.15:35
Takso how do I do a merge on launchpad? normal branch,merge,commit,push?15:56
beunoTak, yes15:57
Pengbeuno: So what did become of the t-shirt?16:21
beunoPeng, I can't ship to the US, so I'm trying to score one in the London office, and send to you via snail mail16:22
Pengbeuno: Ah. That sounds complicated..16:24
beunoPeng, it is, but I will eventually win16:24
PengHow do t-shirts normally make it to the U.S.?16:25
Takso how does that interact with the merge proposal stuff? or are merge proposals just formalities?16:25
PengTak: Merge proposals are an administrative thing, so people can work together to get a branch ready to merge.16:26
Takok, so it's technically unrelated to the actual merging16:26
PengTak: They're of great value, but they're completely disconnected from runn -- yeah.16:27
* Tak nod16:27
PengThat could be changed in the future, of course.16:27
TakI was wondering if I was missing the big green MERGE! button16:27
PengThere already is...something to help automatically merge things, but I don't remember the name.16:28
fullermdOh, there's your problem.  It's chartreuse.16:29
PengWhat's chartreuse?16:29
Lo-lan-doChartreuse is a problem?16:29
Lo-lan-doTry Génépi instead.  It even tastes better.16:29
fullermdThe big MERGE! button.16:29
* Peng looks up chartreuse on Wikipedia.16:30
PengYellow-green? I did not know that.16:31
fullermdThink of how much happier you were 3 minutes ago   :p16:32
PengNow that LP is open-source, I can go download it and change it to chartreuse and set up my own instance, right?16:32
fullermdOnly if you GFDL it.16:33
* SamB_irssi wonders why bzr-search creates so many files in /tmp in the process of indexing a branch...16:36
PengIt does?16:37
SamB_irssiPeng: it sure seems to!16:37
SamB_irssitry it with a branch of lp:coq16:38
SamB_irssiit keeps waffling between files like "/tmp/bzr-index-B4Xk5c" and files like "/tmp/tmpoubU4Q"16:40
jamSamB_irssi: I believe when we create a btree index, we build the content in tmp16:46
jamand then copy the bytes to the final location16:46
jamThat way we don't hold the whole content in memory16:46
jamand we can be sure that we can 'seek', etc.16:46
Takthat explains why I didn't see it - my font color is already set to chartreuse16:53
=== deryck is now known as deryck[lunch]
SamB_irssijam: makes sense ... but you repeatedly open new BTree files in /tmp ... like, way faster than I can run ls17:47
SamB_irssithat part, not so much17:48
jamSamB_irssi: this is while building the index, right?17:49
jamI believe bzr-search creates 1 index per prefix, or something like that17:49
jamI don't know the specific storage mechanism17:49
jambut it creates a *lot* of little indexes17:49
SamB_irssijam: a buttload, yeah17:50
jamand puts them all together and then indexes that, I believe17:50
SamB_irssiwhy does it put them each in a file before indexing it ?17:50
jamthe file you see *is* the index17:54
jamwe just write it to a temp file17:54
jamand then move it across17:54
jami think17:54
jamI haven't researched the bzr-search code much17:54
jamI also believe it builds the index 2k revs at a time17:54
PengThat's right.17:55
jamsearch seems to generate... 4 different indexes18:00
jamrevisions, terms, documents, terms218:00
jamand that may just be the top level view and those themselves have sub indexes18:01
PengIndexilicious. Or something.18:01
jamwell, it has the low level data, then indexes those, shoves all of that data into a '.pack' file as a series of indexes, then creates a 'names' file which is yet another index...18:02
jaminteresting poking at the code a bit18:05
jamit uses 'make_mpdiffs()' to be able to figure out what actual content was introduced in a revision18:05
jamwalking the diff hunks18:05
jamalso interesting is that it doesn't seem to index non-ascii data18:05
jam        _tokeniser_re = re.compile("[^A-Za-z0-9_]")18:06
PengThat would be a good place for one of bzr's lazy regexes, no?18:08
jamPeng: it probably would, but it is done inside an "_ensure_regexes()" so it is already lazy18:08
Peng"_ensure_regexes()" seems more error-prone than a lazy regex to me.18:09
PengAnyway, not the point.18:12
jamPeng: Sure, probably mostly because of timing18:12
jamlazy may not have been available18:12
jamalso, bzr the command line replaces the regex compiler so that *all* re.compile() statements are lazy18:12
=== mrevell is now known as mrevell-dinner
jammore interesting is that bzr-search does a lot of work to make its content compact18:17
jamusing offsets to produce simple integers to do lookups between the different indices18:18
jamI wonder if that is obsolete with btree indices but was never updated to follow suite18:18
Lo-lan-doAny idea why loggerhead would be generating links like <a href="http://zforge.org, zforge.org/scm/loggerhead/testbzr/download/..."?18:20
Lo-lan-do(Note duplication of host)18:20
Lo-lan-doIt seems to do it when proxied through Apache but not when I hit it directly.18:21
Lo-lan-doNevermind, it seems the Apache config does Funny Stuff.18:30
Lo-lan-doSeems maybe I shouldn't try and cascade two levels of proxying…18:31
PengTwo levels of proxying does...that?18:31
PengI guess it gives the hostname at each level of proxying, in case they're different?18:32
Lo-lan-doLoggerhead receives only one Host: header, but "X-Forwarded-Host: zforge.org, zforge.org" (and same for X-Forwarded-Server)18:36
Lo-lan-doI'll debug that after food.18:41
Peng_Prob'ly a Paste thing.18:42
=== deryck[lunch] is now known as deryck
serviliohi! I have a lot of changes in a project that I'd like to partition across a series of commits, is there a tool that helps on this?18:51
phinzeservilio: yup, shelve/unshelve works or if you prefer there's an interactive commit plugin that's pretty nice18:53
serviliophinze: thanks!18:54
LeoNerdI quite like shelve/unshelve, although annoyingly shelve(2) doesn't do partial interactive unshelve, as unshelve1 had18:54
* servilio goes to look at bzr-interactive18:54
LeoNerdSo you either have to shelve up in reverse order, each set of changes, or.. shelve the lot, commit, unshelve, then reshelve again18:54
Lo-lan-doPeng_: Prob'ly, yes.  Any idea how to be sure?18:57
SamB_irssijam: I'm talking a bajillion different files created in /tmp -- not just a few hundred19:00
jamSamB_irssi: are they being deleted?19:02
SamB_irssijam: of course, yes19:04
SamB_irssithere only ever seems to be one at a time ...19:05
jamSamB_irssi: then i'm not very surprised19:05
jambzr-search generates a lot of tiny indices19:05
jamwhen it is done, you could try doing19:06
Peng_Lo-lan-do: Sorry, I don't, except for lots of digging around in the code.19:06
jamgrep 'Graph Index' .bzr/bzr-search/indices/*.pack19:06
jamand you'll see how many it created19:06
jamalso note that it has some logic for combining indices19:06
jamI don't know the frequency, etc19:06
jambut there is a possibility of having significantly more created than the final number19:07
jamSamB_irssi: On my simple index of bzr-search itself (which is a rather tiny project), I have 2928 indices19:07
SamB_irssi% grep 'Graph Index' .bzr/bzr-search/indices/*.pack -c19:08
bialixigc: hi19:08
jamSamB_irssi: that isn't a bajillion, that is only about 200k19:08
jamwell off of a bajillion19:09
bialixhello all19:09
jambut yes, all 200k of those will have created a temp file19:09
SamB_irssithat's still a heck of a lot of temp files!19:09
Peng200k temp files? That's healthy...19:09
bialix200k -- what the hell?19:13
jambialix: 'bzr-search' while generating the search index creates a *lot* of temp files19:14
bialixoh no19:14
jamonly 1 at a time19:14
jambut a lot in a row19:15
bialixthis will be major overkill on windows19:15
jamSamB_irssi: actually, looking at the code, we may be creating 2 temp files per index19:16
jamhence why you saw the bzr-index and the plain tmp-19:16
jamwe create a temp per row, and then one temp for the root19:16
jamwell, temp per row, and then a temp for the final output19:16
Peng_That's, um, a lot of writing.19:18
jamSamB_irssi: out of curiosity, what is the total size of your .pack files?19:23
jamI'm just curious what the average index size is19:23
SamB_irssijam: the index ones ?19:24
jamSamB_irssi: yeah19:24
jamdu .bzr/bzr-search/indices19:24
alfHello all, is there a way to tell bzr-svn to have dpush-like behaviour in checkouts (not use bzr metadata)?19:24
SamB_irssijam: 55 megs, apparently, or 56028 for the command you gave19:27
jamhmm... 288 bytes each19:27
jamlots of small ones :019:27
SamB_irssialf: that would be excessively evil19:28
alfSamB_irssi: why is that?19:30
servilioSamB_irssi: why would that be? for me it would make sense if you are trying to commit to a repo you don't own and don't want to create noise19:30
SamB_irssiI personally think binding to a remote branch is evil period ...19:31
Takhmm, how much does the post-dpush rebase load the server?19:32
SamB_irssino, I mean I think you should look at your commit and make sure you did it right before pushing to the remote ;-)19:33
Lo-lan-doPeng_: Too lazy to debug myself, but I found a workaround by deleting the header in the Apache configuration.19:34
jamSamB_irssi: You may be interested in: lp:///~jameinel/bzr/2.1.0b1-small_btree_no_disk19:36
jamThat uses an in-memory object until the btree > 1 page (4k bytes)19:36
jamthe time for 'bzr index bzr-search' drops from 4s => 1.0s for me19:36
Lo-lan-dohttp://zforge.org/scm/browser.php?group_id=9 now works :-)19:37
ereslibreideas on this guys ? http://pastebin.com/m37a7deec19:37
jamereslibre: upgrade your bzr-gtk19:38
jamereslibre: the ProgressBarStack was deprecated for a long time before bzr-gtk was updated19:38
jam(which didn't happen until we finally removed it :)19:39
bialixjam: senior Fuente insists on newer subvertpy in windows installer. can you update it and provide new installer?19:39
ereslibrejam: thx :)19:39
jamSamB_irssi: on my Windows laptop, that change makes a world of difference in the OS19:43
jamwithout it, the System overhead goes through the roof, and my machine is a bit unresponsive19:43
jamwith the change, the cpu load goes up, but without a corresponding IO overhead19:43
jambialix: I'm happy to change it, but what am I changing it to?19:44
NET||abusehey guys.... trying to update from my laptop to my windows desktop,,, c:\devel\myproject>bzr update     "bzr: ERROR: [Error 123] The filename, directory name, or volume label syntax is incorrect"19:45
NET||abusehtis is when it gets down to a file that is in a tmp directory which should be ignored.19:45
jamSamB_irssi: by comparison, I can index all of bzr.dev in 5m2s, with temp files I was at only 22MB/65MB after 4min19:49
Peng_I'm glad I usually have /tmp as a tmpfs.19:52
alfI was just trying to commit to a checkout of a simple SVN repo and got "bzr: ERROR: exceptions.TypeError: unsupported type None" (along with the traceback).19:55
alfI am using 1.17 (debian). Is this something known/fixed or should I file a bug?19:55
davidstraussalf: Always upgrade before asking/filing a bug19:56
bialixjam: buildout.cfg: subvertpy-release = 0.6.919:56
jamalf: I'm pretty sure that is a known and fixed issue19:57
jambzr-svn was trying to set a revision property to None19:57
jamrather than an empty string, etc.19:57
jambialix: what about the version of bzr-svn itself?19:57
bialixjam: I dunno19:57
bialixjam: jelmer is not very specific19:57
bialixjam: http://bazaar-vcs.org/BzrForeignBranches/Subversion?action=recall&rev=234 lists bzr-svn 0.6.5 as latest19:58
jamI think we want to release the 1.0 series with 2.0 if possible20:01
jambut I don't know where jelmer is in finishing 1.020:01
jamk, I believe Naoki also wanted us to try out tbzr 0.320:02
jamrc2-5 ... coming up20:02
bialixthx jam20:04
alfdavidstrauss: using bzr 2.0rc2 and latest bzr-svn I am still getting a crash, although I am not sure if it is a bug in bzr or bzr-svn...20:26
davidstraussalf: Why are you asking me, in particular?20:26
alfdavidstrauss: only because you were the first to answer me before, sorry20:29
davidstraussalf: Sorry, but I don't know anything about bzr-svn :-/20:29
alfdavidstrauss: no problem20:30
denyshmm... just checking: there is no way I can migrate history to a SVN server to which I only have HTTPS access, right?20:44
Lo-lan-dodenys: If your history is linear, yes you can.20:45
Lo-lan-doIf you have write access.20:45
denysLo-lan-do: what's the trick?20:45
Lo-lan-doAnd if you have a non-linear history, then you can only move one part of it.20:45
Lo-lan-doYou can push to svn repositories.20:46
denysLo-lan-do: you mean: I replay the history?20:47
denysLo-lan-do: bzr-svn + push (I am sorry if this is a stupid question, but I have never done that)20:48
denysLo-lan-do: I have to migrate a CVS module to a SVN server, and I only have HTTPS access to the SVN server20:48
zsquarepluscreally? can't you ask the admin to import a dump of a svn repository? there are cvs2svn tools that work well, you do not need to do the extra conversion through bzr.20:50
denyszsquareplusc: no, unfortunately, there is NO WAY they will allow anything to execute locally on the server.20:51
=== oink is now known as kiko
zsquarepluscdenys: svn can dump a repository to a xml file and svnadmin can mport those again. of course the admins would need to run that, not you. i would hope they already to use that to backup their servers..20:52
denyszsquareplusc: I know this would be possible, but the admins are extremely paranoid and not exactly willing to go out of their way to help. so, that option is unfortunately out. hence my enquiry :-(20:54
zsquarepluscsounds like an IT department of a larger company ;-)20:56
Lo-lan-doMaybe tailor is able to push to a remote SVN repository?20:56
denysjust an IT at a modest university20:56
zsquarepluscdenys: do you really need to use their svn server? use bzr right away ;-)20:57
denysLo-lan-do: things is, I could not see how it could be done using svn functionality - I just wanted to check with others20:57
denyszsquareplusc: it has been a 3 years battle just to get svn with external access.  I would love to get bzr, but that is still "FUTURE WORK"20:58
Lo-lan-doIdeally, you'd pull from CVS into a bzr branch that's bound to an SVN branch with bzr-svn.20:58
Lo-lan-doBut that sounds like a lot of complication.20:59
denysLo-lan-do: the problem is just preserving history with a reasonably accurate timeline (timestamp-wise)21:01
zsquarepluscdenys: well with a distributed system like bzr you don't have to integrate that tightly with system administration. having a smart server may be nice, but bzr also works if you just have webspace where you can push to using sftp :-)21:01
denyszsquareplusc: yes, but the issue is that research oriented projects should be hosted at the university (this is an essential part of the valorization of the work beeing done here).  hosting elsewhere is possible (I have done it) but that's not desirable.  furthermore, sftp cannot work for external collaborations, because there is no way that the university will grant ssh access (even restricted, even when run in VMs as we do) to non-local21:06
zsquarepluscthe external participants would need to host their branches elsewhere ("outside") so that you can merge them in that case. so the "trunk" could be at your place21:08
zsquarepluscdenys: hey you came to bzr so we at least have to try to sell it ;-) you can of course also try to import your code into the SVN repo. bzr-svn may work and there may also be other tools that can accomplish this.21:10
denysthey would still need to authenticate to get locally hosted branches - and that is a problem21:10
zsquarepluschttp+password is possible21:10
denysonly if you are in control of the server, which we are not21:11
denysI have NO access to the server but HTTPS21:11
zsquarepluscits the same setup as you would do for https for svn, only that its not the svn backend but a simple forder you have write access to21:12
denysbut I have NO access. not to a folder. not to anything. its HTTPS or nothing.21:13
zsquarepluscso you do not even have a web page for your project where you can upload files?21:14
denysno, uploading is also extremely difficult.  you need to setup a tunnel through 2 specific gateways.  _I_ can do that, but none of my colleagues could. and the pain, the pain...21:18
RenatoSilvaI want to have software version in each text file of my application automatically. Is it possible? Just like those $xxx$ comments in CVS21:25
fullermd"Keyword expansion" is the ...  well, keyword, you're looking for.21:29
fullermdThere's a plugin for it, but it's not practically usable.  Needs various bugfixes.21:29
RenatoSilvaso bzr doesn't have it in core?21:29
Lo-lan-doIt causes large amounts of headaches in CVS.  Would it be better in Bazaar?21:33
fullermdEverything's better in bzr.21:33
fullermdPonies get distorted by RCS files, y'know.21:33
Lo-lan-doDon't belittle RCS files.  RCS files are going to make me rich.21:35
Lo-lan-doWell, they'll make me money, at least.21:36
RenatoSilvahow to know what rev a file belongs to? I mean, the rev that was the latest to change that file?21:36
Lo-lan-do(Large migration from CVS to Bazaar planned at a client.)21:36
fullermd"I am Sub Version, the widow of the late Premier of CVS.  On his death, he left TEN MILLION DOLLARS in his RCS files.  I require your help to move this out of the country..."21:36
Lo-lan-doRenatoSilva: bzr log $file21:37
Lo-lan-dofullermd: :-)21:37
zsquarepluscfullermd: you get too much spam ;-)21:37
fullermdWell...   I have an email address.  It's tautological.21:38
alfHello, I am trying to understand why bzr dpush needs a rebase afterwards. Can someone point me to an explanation (preferably containing a simple example)?21:39
fullermdalf: AIUI, because what dpush does IS actually a sort of rebased push.  I don't know any details beyond that vague sense though.21:41
zsquarepluscafter the dpush it has to make your local revisions carry the ID of the remote branch again, as otherwise they would not look at being the same? the changesets get a new ID when they are integrated in the other VCS. (maybe this, i don't really know)21:44
zsquarepluscso it integrates all your changes in the other repository and the rebase makes your local branch look as it were checked out from the new head of the remote repo. (?)21:45
alfzsquareplusc: the devil is in the details :)21:46
RenatoSilvaLo-lan-do: thanks21:47
alfLet's say that the svn repo contains revision A-B and you dpush additional revisions C-D.21:51
alfThen the local branch will contain A-B-C-D and the remote A-B-C'-D' (?)21:52
alfHow then is the rebasing performed? I must be missing something.21:54
zsquarepluscafter rebasing, your local repository will also contain A-B-C'-D'  - same contents so they are "in sync"21:55
alfCan rebasing delete revisions (eg C-D)?21:57
dsuchhmm is anyone working on a bzr book?21:58
fullermdDepends on your opinion on the Great Detroying History question.21:58
fullermdIt doesn't delete them from the repository, no.  But they're no longer in your ancestry.21:58
RenatoSilvanot following rebase discussion but I have a question about the one from a time ago22:01
RenatoSilvamerge from trunk for just updating versus rebase (which I have not used yet)22:02
RenatoSilvaisn't the former a mess with your history?22:02
zsquarepluscwhen you work with bzr on both ends you usually don't need rebase i guess22:03
RenatoSilvabecause in pratice if you're working on a feature branch, you just want to keep it up-to-date with trunk22:03
RenatoSilvaI'm just worried about the mess in mistory22:04
RenatoSilvawe'll have seevral artificial commits  "merge with trunk"22:04
zsquarepluscwhy artificial? it was a change in the history of your branch22:05
RenatoSilvais keeping the exact history of what happened, even if it includes those artifical merges (for update purpose), the only reason for preferring the former not the latter?22:05
RenatoSilvazsquareplusc: artificial in the sense that you'd get the same result if you instead of merging from trunk, remove changes, pull from trunk, then apply changes (I think this is rebase)22:06
RenatoSilvazsquareplusc: the question is: is it just about keeping a history???22:06
zsquarepluscrebase rewrites your branches history. so you may get different revision numbers. with merge you do not have this problem. you just get an increment when you commit the merge22:07
RenatoSilvaso you may get different revision numbers? for example?22:08
zsquarepluscin a rebase that can happen. as you can make it base on a different history22:09
* RenatoSilva is back (conn problems)22:11
NET||abusewhen you checkout code from a remote system, do you have to specify an absolute path?   eg,,, bzr init; bzr pull bzr+ssh://me@ipaddr/home/me/code/project1   or can you just specifiy a location relative to your home on the remote system after the host address?22:29
fullermdFull path, until the server's running 2.1.22:31
zsquareplusc1) i'd just cd to to local directory with your projects and use bzr branch22:31
fullermd(or you're using sftp)22:31
RenatoSilvafullermd: so rebase...22:31
RenatoSilvafullermd: I was disconnected22:31
RenatoSilvafullermd: what's the problem of rebase22:31
=== mrevell-dinner is now known as mrevell
fullermdOh, no.  I'm not getting drawn into THAT discussion again.22:32
NET||abusefullermd, ahh,, ok i'm only running 1.1822:32
RenatoSilvafullermd: our conversation was interrupted22:32
fullermdI wasn't in that conversation.22:32
RenatoSilvafullermd: my point is that rebasing (if I understand it correctly) makes the history more natural, even if not that precise22:33
RenatoSilvafullermd: sorry if you wasn't, I thought it was you who wss talking to me22:33
fullermdNo, you were talking with zsquareplusc.  After the 15th or 20th time I watched that discussion unfold, I decided it was an utter waste of time.22:34
fullermdIf you already agree with $ME (for any value of), there's nothing to discuss, and if you don't, nobody is going to change their mind.22:35
fullermdIt's more productive to debate whether god exists, and if so, whether he supports $POLITICAL_PARTY.22:35
RenatoSilvaI think you're confusing me to someone wanting a flame war, REALLY22:37
RenatoSilvafullermd: if you were here yesterday or so you'd know why I was asking22:37
fullermdYeah, that's what everybody says when they open up topics like that  :p22:37
RenatoSilvafullermd: I don't even know how to use rebase or what it is exactly, I just think the idea is good22:37
RenatoSilvafullermd: ok forget the word rebase, I'll explain the problem more strictly22:38
RenatoSilvafullermd: ok forget the word rebase, I'll explain the problem more strictly (ignore if you wish)22:39
NET||abusehmm, i have .bzrignore in the root directory of my WT, is that that right location for my ignore list?22:40
NET||abusei'm finding that some files matching my pattern aren't being ignored.22:40
fullermdIt is.22:40
fullermdWhat suggests they aren't being ignored?22:41
NET||abusethey're appearing in unknown22:41
fullermdOh.  That's a good indication   8-}22:41
NET||abuseahhh wait, they're in another tmp dir near the other tmp dir.... ;P22:41
NET||abusethere's tmp for uploads, and a tmp for captcha's,, i forgot to ignore jpg's in the captcha tmp.... oops22:42
RenatoSilva1) I have feature branch fb cerated from trunk rev 10 2) I submit a few revisions to trunk, which is now at rev 15 3) at the same time I commit to fb, which is now in rev 12 and done 4) I merge fb into trunk and the result is...22:42
NET||abusebzr: ERROR: [Errno 2] No such file or directory: u'C:/Users/Me/Documents/devel/project.com/.bzr/checkout/limbo/new-2/web/public/shared/js/jquery.form.js?2.31"22:43
NET||abusewhat's this about???22:43
NET||abusetrying to pull down from repo on my linux box.22:43
NET||abusewindows version i'm getting this error on is 1.18.1   and linux version is 1.1822:44
=== verterok_ is now known as verterok
fullermdGot me.  There've been occasional weird issues with files being/not being in limbo where they shouldn't/should, but they were mostly older versions.22:48
fullermdIs it happening consistently?22:48
NET||abuseyeh, i completely deleted the copy on the windows machine, then re-init'd an empty branch, and tried to pull into that branch again.22:49
NET||abuseis it something to do with the ? in the file name perhaps?22:49
fullermdPossible, I guess, if that's illegal on Windows.  But I thought all those cases were handled.22:50
fullermdAny particular reason you're init/pull'ing instead of branch'ing?22:50
NET||abuseoh, tried just branching also and it broke.22:50
NET||abusewas first try to just branch.22:50
NET||abusejust as alternate method tried init/pull22:50
NET||abusedidn't try a shared repo yet,,, but i feel this is something to do with the file or that character, rather than antyhing like branch locaiton.22:51
jammorning lifeless22:51
fullermdNo, shared repo wouldn't much matter.  That's all happening in limbo (building the working tree)22:51
fullermdCan you make filenames with question marks in them?22:51
fullermdjam may be more helpful than I...22:52
NET||abusei'm actually just deleting the file from the branch on linux machine, and trying now, it was just a copy of the downloaded jquery.form 's plugin.22:52
jamfullermd: ? is illegale22:52
jam\ / * : ? | " < > are all illegal22:53
pooliehi jam22:53
jamhey poolie22:53
fullermdWell, that would 'splain it then.22:53
fullermdThough I thought we had traps to give more pointed errors in cases like that.22:53
jamNET||abuse: I would agree with fullermd that I thought we would at least give a nice error for this case. But we can't create them so you need to delete them on another machine (for now)22:54
NET||abuseeh, yeh,,, problem solved... hmmmm so no ? marks in windows version.22:54
NET||abuseguess it could be an ntfs problem.22:55
NET||abuserestricted characters22:55
jampoolie: let me know when/if you want to call22:55
pooliejam, hi, i do want to call22:56
pooliei'm just finishing something up here and i'll call in a few minutes22:56
jamhome is probably easiest, but skype is fine too22:56
lifelesshi jam23:01
lifelessso the cStringIO thing; my original thought was 'probably won't hit disk', I think.23:01
lifelessjam: but I'm glad to have it be nicer for windows ;)23:01
jamlifeless: well, it has to allocate an inode, etc23:01
jamI'll try checking it on a linux box23:01
lifelessallocating the inode doesn't have to hit disk, until fsync on the containing dir23:02
lifelessanyhow, I've +1'd23:02
jamyeah, I sawthat23:02
pooliejam, calling23:02
NET||abusehuh.. when i have parent branch: bzr+ssh://me@ipaddr/path/to/repo    but then bzr push says no push location23:10
NET||abusesorry for the basicness of this, it's just a bit of a confusion23:10
fullermdpush doesn't use the parent location by default.23:11
fullermdIt has its own.23:11
NET||abuseohhh,, how do i set that then?23:11
fullermdYou can use the saved loc shortcut to set it quick (`bzr push :parent`)23:11
NET||abuseahhh, ok23:13
NET||abusebit confusing though isn't it?23:13
fullermdThe operative theory is that push'ing to somewhere other than you branch'd from is a very common case.23:14
fullermd(e.g., you might often branch from a location you can't write to)23:14
NET||abuseahah,, that's true.23:15
NET||abusei guess.. it's just more a ,, where do i look for those instructions?23:15
NET||abusethey're not very obvious, even after reading the workflows documentation.23:15
fullermdContrast with merge, which also has its own stored location, but will use the pull loc if that's not set.23:15
zsquarepluschm. when that :parent shortcut works in such cases, it would be worth mentioning that in the error message of push when it has not yet a saved location23:15
fullermdFirst, merge'ing from your original base is more common, and second, if it's NOT what you want, accidentally doing so isn't near as harmful.23:16
fullermd(if you accidentally push somewhere you didn't intend, it can be much harder to undo)23:16
fullermdNot sure what instructions you mean.  If you mean having to supply a location when none is saved, that's common to pretty much any command (including pull).23:16
fullermdIf you mean the shortcut names, last I heard they weren't documented.23:17
fullermdTheir existence is mentioned buried in NEWS, but last time I wanted to know what the choices were I had to dig into the code.23:17
fullermdThat was a while ago, though.  Maybe they're in the manual.23:17
zsquarepluscwell i did not know about it, i always had to specify the same URL 3 times.. branch then pull/merge and push :/23:17
jamlifeless: so on an old linux box, indexing 'bzr-search' itself: 4.894s => 2.426s23:17
fullermd(I haven't followed the progression of the documentation as closely as I should  :| )23:19
fullermdzsquareplusc: You certainly shouldn't have to specify it on pull after branch.  branch sets the parent loc.23:20
zsquarepluscfullermd: with instructions i mean instead of just "bzr: ERROR: No push location known or specified." it could additionally mention what's possible23:20
fullermdWell, what's possible is specifying it.  Trying to describe all the possible forms that can take is *way* out of scope for an error message.23:21
fullermdIt _should_ (in the sense of 'out to', not 'I think is') be in the docs.23:22
fullermdHoly crow.  "ought to".  My fingers are not my friends today.23:22
zsquareplusci'd not mind short usage tips when i'm doing something wrong. better than nothing and "good look to find it in the manual"23:23
fullermdGiving useful tips in a situation like that is bzr-dwim territory  ;)23:24
alfI am experimenting with bzr-svn and have created a branch of an svn repo. I have commited something on local branch and something in the svn repo so they have diverged.23:25
zsquarepluscwell an an option is when the help is built in to give at least a hint on how to get that help, e.g. if there were a "bzr help location" it could direct the user to read that.23:26
alfI am trying to push to the svn and of course I cannot due to the branches having diverged. So I merge from svn to the local branch.23:28
alfNow when I try to push to the svn it says that Operation denied because it would change the mainline history...23:29
alfI am wondering in what way my push  will change the history on the svn.23:30
fullermdsvn can't represent the history bzr has, and the standard projection into lower dimensions (as it were) differs from the existing history.23:31
zsquarepluscso is this one of the use cases for rebase?23:34
alfso if svn and its bzr branch have diverged, is there a way to perform the merge from the branch->svn without changing the mainline?23:34
alf(I mean the mainline history)23:35
fullermdGenerally, by doing the merge the other way around, so the svn history and bzr mainline coincide.23:36
alfI don't think I got that. If my branch and svn have diverge what steps do I have to take to get my branches changes to svn (without history changing)?23:39
fullermdMerge the bzr changes into the svn changes, rather than the other way around.23:40
fullermde.g., have a checkout (not a branch) of the svn branch, and a bzr branch in which you do the work.  To land it, merge it into the checkout and commit it.23:40
alfahh, ok23:41
fullermd(you could use a branch instead of a checkout of course, but a checkout can be conceptually more accurate)23:41
fullermdBasically, you want to end up with "merge my-changes ; push" rather than "merge upstream-changes ; push"23:41
alfif I use a branch isn't the situation the same as the one we have been talking about?23:42
fullermdNo, it's not really branch vs checkout, it's a question of which side of the merge you're on.23:43
fullermdCheckout just conceptually fits what you're doing (merging stuff into the svn 'branch') and suits staying in lockstep.23:44
RenatoSilvaI'd appreciate very much if you could read this http://pastie.org/625271 :)23:46
RenatoSilvahttp://pastie.org/625271 - update-merges vs. rebase23:46
RenatoSilvathat's an example where I put how would it be in both cases23:47
alffullermd: thanks for the explanation, I think after some processing on my part things will become clear23:48
zsquarepluscRenatoSilva: i don't think that this will work in all cases. you known that with rebase, you can run into conflicts while rewriting the history?23:52
RenatoSilvazsquareplusc: see I'm not agueeing, I'm learning. No I don't know23:54
RenatoSilvazsquareplusc: what proplems in that example could get wrong?23:54
RenatoSilva* argueeing23:54
RenatoSilva* arguing23:55
RenatoSilvazsquareplusc: in that example specifically, no history is really rewritten, it's just like starting the work again after each update in trunk23:57
RenatoSilvazsquareplusc: e.g. you could replace steps  3.[2,3].2 with "forget it all, do the same code changes again manually"23:58

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