[00:22] mgz, how come? :-P [00:28] because it's bed time, just trying to finish livecd backup [00:31] (as you may have gathered, this does mean I am actually still awake, and mostly watching progress bars) [00:42] mgz, ah, though you were an American for some reason. [00:42] mgz, still want me to write that blog post about setting up bzr+ssh on windows? :-P [00:42] might get some time tomorrow [00:42] s/might/should [00:42] s/tomorrow/weekend [00:51] would be great if you could [00:57] ok will do :-) [00:57] back in the mood of blogging since recently [00:57] so shouldn't be too hard [11:44] * jelmer waves [13:25] hi, is someone here speaking french ? [13:44] perhaps speaking german ? [13:49] how does branching work with colocated branches? [13:49] if i do 'bzr branch . "something" " [13:49] then it creates the branch inside the owrking tree inside of the .bzr/branches folder [14:27] anyone on irc? :> [14:40] hic [14:41] hey [14:41] first off: i still need to fix the stuff we were working on, couldn't really come on cause my video card on windows decided to die hehe [14:42] second off: [14:42] mr Movix is trying to set up a sepcific workspace flow thingy, is it possible to have a branch that has branches underneath it? [14:43] well, I'm just hanging around eating stollen, so can help out [14:43] thx, i appreciate a lot [14:43] Movix is the one with the cms/php complicated setup thing? [14:44] oh ! seems so ! [14:44] well it seems that it would just be solevd with a branch with branches underneath [14:44] and i see bzr has "split" which does that [14:44] but...then it wants to version the newly created branch [14:44] what he's directly asking for is nested trees I think, which... is not fully implemented and still rather complicated [14:44] yeah. [14:44] it wants to version the repo files and stuff and that doesn't seem right [14:44] what he really wants is probably just a less complex way of working [14:45] ok, that reconciles me with bazaar, because i allready thought i'm to stupid for this stuff [14:45] i feel you would have this problem with any vcs honestly [14:46] right. [14:46] yes, i was afraid about it but came to this conclusion also [14:46] you could also use symlinks [14:46] but again there is windows, and the bug which i need to try and see if i can fix >.> [14:47] subversion has reasonable support for integrating different related branches, but it's still fiddly to work on [14:47] I think really, what you want is: [14:47] * A pristine upstream branch of the cms [14:47] * A branch from that, with your changes and modules [14:48] at this point i have my first issue [14:48] * A number of "known good" or release branches, which you don't work on directly [14:48] then merge selectively downwards [14:49] i do not want to have the cms files mixed up with the module files, or i need to have a simple way to extract only the module related files in order to make a module only release [14:49] bzr export subdir works [14:50] as does bzr merge, and selective revert [14:50] eg [14:50] you have branches Upstream, Development, and CurrentRelease [14:51] i did not understood the selective reverts Martin allready suggested to me on launchpad [14:51] yes i allready tested taht structure [14:51] and it indeed comme the closest to what i expect [14:51] if you want to update one module in CurrentRelease to what you have in Development, but won't want any of the other changes [14:52] let me please say this in my own words to make sure i unterstood it well [14:53] what do you mean by "any of the other changes" ? [14:53] okay, give an example [14:53] well, I'm imagining you just do all your own changes in Development currently [14:54] so, you've updates module/x but also changed various other things in templates and maybe updated to the latest upstream version [14:55] if you know which changes you want to land on an existing release in advance, you work on those in a seperate branch [14:56] but even if you don't, you can merge or cherrypick merge just the changes to module/x without including all the others [14:56] so, you don't need a seperate version control branch for each module and template [14:57] which makes life complicated, as you then need to track everything seperately, but also record which versions of each branch work with which versions of other branches [14:57] that's the point [14:58] generally it's sufficient to just commit independant changes as seperate commits, and keep branches in a known-working state [14:58] so i finaly made my life easier on one hand but complicated it on another [14:58] people seldom care in practice about full dependency tracking for each tiddly component of a project, they just want a few known correct states [14:59] i'm happy to see that most of my conclusions were not so weird [14:59] so, you have a 'stable' or similar branch you want to keep existing versions, but perhaps selectively update certain things [14:59] correct [14:59] that you can do by just branching from an older revision, and cherrypicking or daggy fixing certain modules [15:00] have to give a look at cherrypicking, i did not looked at it for now :( [15:00] or, say, you want all your modules unchanged, but need to update the base cms to the latest minor version with security fixes [15:00] all you need in that case, is your pristine upstream branch of the cms [15:02] update and commit the new version, then `bzr merge -d StableRelease Upstream; bzr commit -m'Update to X.X.1'` or similar [15:02] if upstream has multiple branches going at once, it still works, you just keep a branch for each series [15:02] some of this is easier to do with pictures :) [15:03] so, with merging backwards to stable like this, there are three basic options: [15:04] * Merge the newer branch, revert every change you don't want, and commit [15:04] * Cherrypick merge just the revision with the change (this is similar to just commiting the applied patch) [15:06] * Do the fix on branch at a revision before stable diverged, then merge into both development and stable branches [15:08] AuroraBorealis: so, is your gfx card fixed now? what's our next step? [15:08] well [15:08] its fixed now [15:09] but i think my disk might be screwed up cause i seem to be creating a lot of undeletable files === yofel_ is now known as yofel [15:10] so i'm going to try and fix this before anything else [15:10] HOWEVER [15:10] * mgz fears hardwar :) [15:10] +e [15:10] but I guess hard war too. [15:10] are colocated branches fully supported yet? [15:11] yes, they need some ui work still, but go ahead and poke them/file bugs [15:12] because i'm not exactly sure how to create another branch inside of one [15:13] that's... nested trees, not colocated branches? [15:13] i created a 'colocated branch' in bzr explorer [15:13] and the branches are stored in .bzr/branches [15:13] colo is just about having one directory represent more than one branch [15:13] that seems interesting to me [15:14] yeah, so shouldn't it be possible to have more then one branch in the same directory? [15:14] for my needs^^ [15:14] cause i thought thats how git does it [15:14] in your case Movix, you're more likely to get deeply confused by colocation than find it useful I think [15:15] and then you use switch to switch between branches [15:15] you need to keep in your head that you're only working on the development tree, and merging changes around [15:15] may i post here what i understood from your suggestions to verify i understood it ? [15:15] right, so, that all works AuroraBorealis, what aren't you succeeding tat? [15:16] Movix: go for it [15:16] well creating a branch in a colocated branch [15:16] creates it in the wrong place it seems like [15:16] `bzr switch -b newbranch` is all you need for a new branch in the same dir with a colo format [15:17] it's in .bzr/branches under the hood, but you can address it with the funny comma syntax [15:17] yeah [15:17] that doesn't seem very..intitutive [15:17] i was trying to do "bzr branch . somenamehere" [15:18] okay, so, file bugs/post to the mailing list about the bits you find confusing [15:18] and the fact that to create another branch you have to use switch xD [15:19] you can do it with the branch command, but... the addressing is ugly [15:19] need something like `bzr branch . file:,branch=newbranch` [15:20] hm =/ [15:20] the problem with what you tried is it works as a command meaning something else [15:20] yeah [15:20] it created a new branch [15:20] but it didnt do it in the way that colocated branches expected it [15:21] I use exactly that with python and mercurial, branch from the (treeless) current dir into a new subdir (and create a tree) [15:21] if that's a common issue, trapping it as a mistake and warning or something may be useful [15:21] as in you branch inside the .bzr/branches folder [15:21] directly? [15:22] no [15:22] to build my structure i do this [15:22] bzr init bzr/cms [15:22] bzr commit bzr/cms -m "Project init" --unchanged [15:22] bzr branch bzr/cms /bzr/upstream [15:22] bzr branch bzr/cms /bzr/dev [15:22] bzr branch bzr/cms /bzr/currentRelease [15:22] i copy my downloaded cms files into /bzr/upstream, do add and comit -m "cms version xy" [15:22] now i have to push this to my paent branch bzr push /bzr/upstream /bzr/cms [15:22] and can get his update in my dev branch bzr pull /bzr/cms /bzr/dev [15:22] now i add my module files or do some work that once finished is comited bzr commit /bzr/dev -m "Mymod init" [15:22] If i'm still wrong on these first steps i appologyse to have wasted your precious time [15:23] Movix: roughly seems fine, some comments in a sec [15:25] AuroraBorealis: no, it's something of a quirk with the python/hg setup, they have different development series bundled into one, so to get a tree for each version, I branch the whole lot into python/ without trees, then do (the hg version) branching python/ into python/2.7 to get just that branch with a tree [15:25] ah [15:26] interesting [15:26] in bzr, there's really no good reason to create a new branch from the current directory to a subdir [15:26] yeah [15:26] because we have shared repos [15:26] well i was just trying to see how you create another branch in a colocated dir [15:26] yup. [15:26] i'll file a bug report on saying thats hard [15:26] so, the right answer is switch -b, it's just not very obvious [15:26] also: where should i file documentation bugs? [15:27] yeah, i feel branch should be smart and do it correctly if its in a colocated branch [15:27] against bzr generally. perhaps posting a selection of impressions to the list would be most useful [15:27] well i just notice that 'bzr new' is not on the online documentation at all [15:27] and then doing bzr new --help says "usage: bzr init-workspace [LOCATION] " [15:28] so that is wrong as well [15:28] ...seems to be from bzr-explorer? [15:28] oh. [15:28] it even says that. [15:28] at the bottom. [15:28] well, i'll file that against explorer [15:29] Movix: so, you don't need to do that empty commit at the start, and want to branch from upstream to dev, and from dev to currentRelease [15:30] I'd suggest... unpack upstream release to bzr/upstream then bzr init and bzr commit there [15:30] ok [15:31] then branch that to bzr/dev then branch bzr/dev to bzr/currentRelease [15:31] now copy across your working development file into bzr/dev and do `bzr st` [15:32] check it looks sort of right, add anything you need to, commit [15:32] you may want to look at `bzr ignore` before that, all three branches will want it probably [15:33] (it's less important for upstream, as you may not need to build/test that locally) [15:34] anyway, after that you can try merging those dev changes to currentRelease and reverting some of them [15:35] remember you can always chuck some branches away, create new ones, branch from old revisions, and such like [15:35] so should experiment as much as possible [15:36] thanks for the help, i'll try and fix my windows problems and get back to working on the memory stuff [15:36] but now, bed~ [15:53] thanks so far for your help, i go back testing [15:54] feel free to keep bugging me [16:01] (16:27:56) mgz: you may want to look at `bzr ignore` before that, all three branches will want it probably [16:01] you meen i'll ignore the files issued from the CMS sources (or part of these) ? This does not work because there are issued and commited in the parent of bzr/dev [16:04] no, I mean ignore anything you don't want versioned [16:05] ok, i continue testing [16:05] like stuff automatically created when running in place or whatever [16:05] ok, understood this [16:06] will just be nipping out with hound, should be back shortly [16:18] mgz: Back again ? [16:42] mgz: are you here ? [17:05] Movix: back (briefly) [17:06] yeah, i just want to say that i got a quite good result now [17:06] the cherrypick is the way [17:06] using the suggeested structure [17:08] but when releasing a module branch /bzr/dev /brz/modulerelease.xy i have to cherrypick all changes to the branch that do not concern the module. that needs to relosve a lot of conflict on that path but finally i have a clean module release folder [17:10] i guess i have to keep the message in the explorer when within bzr/dev that tells me not all changes are merged to the parent and never murge them. tu update to a new upstream release release, i delete contents of bzr/upstream and populate that folder with the new downloaded files and commit this. after that i grab it within the dev folder with a pull merge command. [17:10] anyway, thank you a lot for your effort in understanding my bad english and the time you spent for my concerns [17:22] I don't quite follow that, but you don't really want pull from dev to release [17:23] you just want merge, either -r31..32 for one specific change, or all changes then reverting and subdirs you don't need, which remembers not to try and bring in those changes again === GRiD_ is now known as GRiD === verterok` is now known as verterok