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