igclifeless, poolie: I'd like to put a patch up for per branch rules again00:06
igcI'm thinking of a .bzr/branch/rules file that doesn't propagate00:06
igcala branch.conf00:06
lifelessso some questions00:07
igcDoes that sound ok?00:07
lifelessa) why not put it in branch.conf00:07
igcI'll look into that00:08
igcI suspect formatting might be an issue (but it might not if we agree to allow nested sections)00:08
lifelessand sure, it sounds ok; presumably you need wt5 to use it, but you may be able to get away without a new branch format object as its not affecting historical data00:08
lifeless(I honestly prefer new objects every time, but I get the objection folk have to that)00:09
fullermdIf it really affects the WT primarily, why put it in .bzr/branch/?00:10
lifelessfullermd: that was my next question :). But I can come up with an immediate use case - checkouts00:10
* fullermd doesn't follow.00:11
lifelessigc: so here is a thing to think about00:11
lifelessigc: consider a loom, or a git-branch-style setup00:11
fullermd.bzr/checkout/ is always there (at least, unless there's no WT, in which case rules don't mean anything anywho)00:11
lifelessigc: 'bzr switch foo' - that will have to backout-gone-and-apply-new rules00:12
igclifeless: yeah, good point00:13
igcif it were .bzr/checkout/rules, that wouldn't be the case right?00:13
lifelessigc: I think the root of the concerns I had about version-propogating rules derives from this basic thing; these transformations are inherently local to the tree object00:14
lifelessbut the proposed design really started/wanted to treat them as something related to the project - which we have no effective abstraction for00:14
lifelessigc: right, .bzr/checkout/rules would keep a constant ruleset during 'bzr switch'00:15
lifeless(in the absence of any other places for rules to be sourced)00:16
igclifeless: I expect tree-specific rules to override those in .bazaar/rules00:16
lifelessigc: .bazaar/rules is constant for a single invocation though. I was referring to e.g. .bazaar/locations.conf based rules00:17
lifeless(which is another case of trying to allow rules to be included in normal config files000:17
lifelesshmm, I didn't mean to sidetrack things00:21
lifelessgetting a non-propogating tree-working-with-rules thing that people can use today++00:22
igclifeless: thanks for the feedback. So I think we're agreed that .bzr/checkout/rules would be a step forward without causing obvious problems down the track?00:25
lifelessigc: myself, I have a directory with all my trees for project X00:31
=== ubott2 is now known as ubottu
lifelessigc: so *I* would want, until we have a good answer for 'project' to configure them in locations.conf00:31
igcfullermd: implicitly knowing "the rules" just seemed the bzr way00:31
lifelessigc: its where I configure email settings and default push locations00:32
lifelessigc: which are the other project-wide settings I work with today00:32
igclifeless: I think we greatly under-utilise locations.conf as a feature of our product00:32
fullermdOne way to choose which problem to cause is considering the knock-on effects of each choice.00:32
fullermdLike, if you plunked it in branch.conf, it could be used to try and force a resolution of the "allow per-branch config that propogates" chewtoy.00:33
lifelessigc: I agree we want to end up with just knowing the rules, as much as possible00:34
igcfrom memory, I originally proposed rules inside nested sections of branch.conf and locations.conf (and it got knocked back). Perhaps it's worth reconsidering that. I still have the branch supporting nested sections. :-)00:35
lifelesslunchtime, got some chores to run too, back in a bit00:35
=== Mario__ is now known as pygi
igcfullermd: yes00:39
jmlremind me, how do you change the branch location of a working tree?00:42
jmlsay you've renamed the branch and want the tree to point to the new location00:42
spivjml: "bzr switch" maybe?00:43
jmlspiv: it raises errors about the old branch not existing00:43
spivHmm, I thought I saw patches about that bug a while back.00:43
spivThe crappy way is to edit .bzr/checkout/something00:44
igcHmm - I'm talking crap. My nested sections stuff was related to defining shell hooks, not rules, it seems00:44
jmlspiv: there doesn't seem to be a reconfigure either.00:45
jameshperhaps switch could do something sensible if the working tree's basis revision existed in the new branch?00:45
* Peng_ finally deletes old .pyc files. When was bzrlib/plugins/multiparent.py removed? :P00:47
Peng_ /renamed/whatever00:47
fullermdOh, heck, not even a year ago.00:49
jmlspiv: I filed https://bugs.edge.launchpad.net/bzr/+bug/31389800:50
ubottuError: <Bugtracker.plugin.Launchpad instance at 0x865470c> bug 313898 not found00:50
fullermdTry bug 285055 and bug 30879800:51
ubottuLaunchpad bug 285055 in bzr "switch --force on lightweight checkout connects to original remote branch" [Medium,Fix committed] https://launchpad.net/bugs/28505500:51
ubottuLaunchpad bug 308798 in bzr "Unable to switch lightweight checkout when it's parent branch is renamed" [Undecided,New] https://launchpad.net/bugs/30879800:51
spivjml: thanks00:54
=== Mario__ is now known as pygi
igcabentley: can you bounce BB please if you're around?01:05
jmlhow would y'all feel about a bzr command that opened a branch's web page in Launchpad in the user's default browser?01:13
beunojml, it would make me cry of joy01:15
AfCjml: we don't use Launchpad, so I wouldn't notice.01:16
jmlcool. I'll file a bug and say I'll mentor it (and maybe jfdi later)01:17
jmlbeuno: https://bugs.edge.launchpad.net/bzr/+bug/31391601:21
ubottuUbuntu bug 313916 in bzr "Command to open a branch's web page in Launchpad" [Undecided,New]01:21
AfCjml: now. If the branch metadata carried general notions like "our home page is $x, and our bug page is $y, etc" then a "Command to open a branch's web page" would be superlative.01:23
jmlAfC: yeah, I mention that on the bug.01:23
AfCjml: otherwise it's just another feature that makes people think that Bazaar is only for people who work at Canonical.01:23
AfC[as evidenced by the FUD in the latest GNOME VCS thread]01:24
AfC[but a) we're going to lose that one, and b) who cares, so that's not a very good example. The point holds, though]01:24
jmlAfC: the bug metadata is already there... it just has lousy APIs and not much in the way of command line access01:25
AfCjml: I would define that as "not actually there" then, but {shrug}01:26
jml(o for a thousand days to hack)01:26
AfCbut the sun is out, and it's 30℃, so forget hacking. I'm going to the beach.01:27
=== Mario__ is now known as pygi
* igc lunch02:05
rockstarIf I deleted a file in one branch, and in another branch it was moved, how do I resolve the conflict when I merge that other branch, so that the file is deleted?02:15
lifelessrockstar: if it was just moved it shouldn't conflict, if it was moved and edited then the edit will cause a conflict. Just remove it again02:16
rockstarlifeless, I can't because the file doesn't exist...02:16
lifelessrockstar: bzr st02:16
rockstarAh, bzr resolve <path/to/file> worked.02:16
rockstarPath conflict: <deleted> / tools/run_debug.py02:16
rockstarlifeless, ^^02:17
=== Mario__ is now known as pygi
=== Mario__ is now known as pygi
lifelessmarkh: btw with bugs02:38
lifelessmarkh: you don't need to make things invalid on bzr, you can just edit the task to say its for bzr-gtk only02:39
=== TheMuso_ is now known as TheMuso
lifelessspiv: ping03:31
spivlifeless: pong03:33
lifelessbrisbane core has some networking implications03:34
lifelessdo you have a branch working on generating a stream03:35
lifelessfor push and pull03:35
spivI do, for push.03:35
spivhttp://people.ubuntu.com/~andrew/bzr/streaming-push (it's a loom)03:35
lifelessare there docs on the wire format you're putting together? I'd like to collaborate on that early03:36
lifelessalso, have you looked at what git does to determine the objects to include in its wire transfers?03:37
spivlifeless: hmm, no docs yet, although it's still in flux a bit.03:42
spivlifeless: it's more-or-less a series of bencoded tuples of the attributes of the ContentFactory objects returned by get_record_stream03:43
spivAnd no, I haven't looked at what git does.  Or rather, I've looked a bit, but I didn't manage to locate any clear docs on the subject so I went and did something else :)03:44
lifelessok, well to figure out anything git does I've found reading the source the best way03:44
spivI don't suppose you have a bzr mirror of the git source handy? ;)03:44
lifelesswhat about the actual delta content03:46
* jelmer has enough knowledge about the git wire protocol now that he's implemneted it :-)03:46
lifelesslet me be more precise in a couple of ways03:46
lifelessjelmer: what I want is the algorithm for determining objects-to-include and objects-we-can-use-deltas-against03:46
spivjelmer: I take you used the source to learn about it?03:46
lifelessjelmer: if you could write that up that would be great03:46
jelmerlifeless, that's two different processes03:47
jelmerbasically what happens is:03:47
lifelessjelmer: things like is it chatty, does it assume cheap heads-lists, does it use the reflogs and so on03:47
jelmer-> server sends list of HEADs it has03:47
jelmer<- client sends "want <rev>" for each <rev> it wants to end up with03:47
lifelessjelmer: this is push or pull use case?03:47
lifelessjelmer: also is this full duplex or back and forth on each item03:48
jelmerthen the client starts sending "have <rev>" for the ancestors of its local heads, until the server confirms it has one of those revisions03:48
jelmerlifeless, this is pull03:48
jelmerlifeless, it's full duplex03:48
jelmerso the client may see one of the acks from the server too late, but that's not a problem as sending a couple more "have <rev>"s is way cheaper than spending a roundtrip on each revision03:49
lifelessbreadth first traversal I presume03:49
jelmerafter this process, the server sends the complete contents of a .pack file that can be written to disk immediately03:50
lifelessand it does this per-local-head or all-in-parallel? if its all-in-parallel, does it trim when a particular head is reached03:50
lifelessor just keep going until all have had revs reached03:50
lifelessor until any-rev is reached?03:51
lifeless[I can rephrase this as - whats the algorithm, as opposed to the mechanics:P]03:51
jelmerit obviously stops sending "have <rev>" for the ancestors of a particular head as soon as the server has confirmed it knows about a particular head03:52
jelmerit obviously stops sending "have <rev>" for the ancestors of a particular head as soon as the server has confirmed it knows about a particular *ancestor* of that head03:52
lifelessdoesn't it need to know all ancestors? I mean, consider a:[b,c]03:52
lifelessif the server says it knows b, and we want a (but don't have a) that doesn't imply that the server has c03:53
lifelesserm bad example. a:[b,c], b:[d,e]03:53
jelmeryes, it needs to know all ancestors03:53
lifelesswant: a03:53
lifelessanyhow, this is not surprising, its what I thought it did :)03:54
lifelessthe key differences to bzr are server-state-is-accrued and full-duplex03:55
jelmeryeah, it's not rocket science but it is a really fast protocol03:56
lifelessthese are only rev ids though right, it doesn't recurse into dir objects at this stage03:56
lifelessit infers those when building the pack03:57
jelmerlifeless, yes03:57
jelmerlifeless, same for what to delta against what03:57
lifelesssecondly, I thought git had thin packs for pull and push03:57
jelmerwhat are thin packs supposed to be?03:57
lifelesswhich were *not* written verbatim to disk but instead expanded to meet the normal assertions about pack content03:57
lifelessthey are packs which have deltas external to the pack03:57
jelmerlifeless, ah, right03:58
jelmerlifeless, but at least as far as I can tell, those can exist in regular git packs as well03:58
jelmerand if not, we have a dulwich bug :-)03:58
lifelessoh also the HEADS list is something we try not to do, because that list can be _big_03:58
lifelessno, they are not meant to exist in  regular git packs03:58
jelmerlifeless: sorry, it's the list of refs in the case of git, not the list of heads04:00
jelmerI don't think there's an easy way to find all heads in git even, short of scanning the repository (much like bzr)04:00
lifelessjelmer: ah goo04:00
lifelessso thats name:revid?04:01
jelmerbasically, yeah04:01
lifelessspiv: back to our discussion04:01
lifelessjelmer: it was useful04:01
lifelessjelmer: still not clear on the logic for whats assumed held by the client for thin packs04:01
jelmerlifeless, what do you mean with held by the client?04:02
jelmerlifeless, what sha1-objects are held by the client?04:02
lifelessjelmer: if you wanted to dig that up it would be interesting. (imagine a local repo with alternate A pulling from repo B - a thin object reference that is in A and not local would require another network op to fix the thin back  (see git-index-pack --fix-thin).04:02
spivlifeless: so, the current struct I send for a record is (sha1, record.storage_kind, record.key, parents, build_details, record.get_bytes_as(record.storage_kind))04:02
spivlifeless: jam has asked that I add the compression parent to that, for obvious reasons.04:03
jelmerlifeless, "alternate A"?04:04
jelmerlifeless, there is no such thing as ghosts04:04
lifelessjelmer: look up git alternates - stacked repos04:04
lifelessspiv: well compression information should be specific to the compressor04:05
spivRight, that would be ideal.04:05
lifelessI think you should refresh your memory of http://www.kernel.org/pub/software/scm/git/docs/technical/pack-format.txt at some point soon04:06
lifelessjust as a reference04:07
lifelesse.g. we don't need the sha1 in this stream, its dead space. We can sha the entire stream for integrity checking04:07
lifelesswhat are the build details?04:08
spivrecord._build_details for 'knit-*' records, otherwise blank (signified by an empty tuple).04:09
lifelessspiv: have you looked at group compress04:10
spivNot recently.  It's probably about time I refreshed my memory.04:10
jelmerlifeless: As far as I can tell there's no particular special-casing for alternates so that would indeed require another network op04:10
lifelessrinse and repeat, thats the entire format04:11
jelmerlifeless, not entirely, the delta'ed entries don't have a sha104:11
spivBasically the serialisation at the moment is pretty simple-minded, it just dumps out the attributes so that it's easy for the remote side to construct an equivalent object.04:11
lifelessit will not fit at all well into what you seem to be proposing04:12
lifelessspiv: yeah, thats what we did last time, and why I want to engage on this early ;)04:12
jelmernm, I thought you meant the separate entries04:14
* jelmer gets some sleep04:14
lifelessfirst suggestion I'd make is that your current bencode tuples be marked as substreams - a pathological case if you like (only one element)04:15
lifelessbut that would allow a number of group compress streams to be embedded04:15
spivSo, which things are constant for all records, and which can vary?04:15
lifelesseach of which contain N actual texts04:16
spiv(key, sha1, record_kind), and everything else depends on record_kind?04:16
lifelessnope, a step up04:16
lifelessstream = [substream ...]04:16
lifelesssubstream = gcstream | knitstream | weavestream04:17
lifelessknitstream = [bencode tuple ...]04:17
lifelessgcstream = to be discussed (does it support parent meta-data, or is that forced up a level, etc)04:18
lifelessweavestream = a weave verbatim04:18
spivOk, although that doesn't fit 100% neatly with the get_record_stream API.04:18
lifelessit should fit perfectly04:18
lifeless(the intent of get_record_stream is to be a least-assumption API, not to reflect what is in a wire byte sequence)04:20
spivI was thinking about stacking, but I guess that's handled by the caller of the repo(s), not the repo itself.04:22
lifelessthat was one of the problems with the prior network stream - it was setup to fit the knit api04:22
lifelessbut the knit api was random access and quirky04:22
lifelessI'm not sure how stacking fits in here04:23
jmlis there a way to do 'bzr log -r(tag:foo+1)..'04:25
lifelessspiv: so the fact there are knitstreams as subelements wouldn't be exposed by the api04:26
spivThere's no "after:" rev spec.  There's before:, but that's easier to define.04:26
spivI guess after: might be well-defined in the context of a particular branch.04:27
lifelessspiv: as for the individual text record, sha1: is redundant IMO, we should be aiming to regenerate the text as we receive it to determine the sha1, to prevent bad data being sent to us04:28
spivlifeless: right, taking bytes off the network and turning them into a stream is straightforward there.  But taking a stream and turning it into bytes seems less neat to me.04:28
lifelessspiv: which is supported by the record stream API (None for sha1)04:28
spivProbably you just peek at the first record to figure out what sort of (sub)stream to serialise.04:28
lifelessa stream->bytes adapter would be nice04:29
lifelessI imagine it would start with an empty output stream04:29
lifelessthen start eating records and outputting them as bytes, with record-storage-kind adapters to do things like eat all the records of a weave but output just the weave04:30
lifeless[though weaves are a bad example because they just generate FullTextContentFactory objects, as I wanted 'works' not 'optimal'04:31
lifelessgit-pack-records, for reference, holds a little metadata about every object, then decides based on that how to retrieve it and how to include it04:31
lifeless(e.g. to just copy it, or to extract and redelta, etc)04:32
lifelessconcrete example though, in gc, record.get_bytes_as(record.storage_kind) -> nonsense-data04:33
lifelessso, I started at 730 this morning, I'm going to call it now ;)04:39
lifelessgnight poolie spiv igc jelmer etc etc etc04:39
igcnight lifeless04:39
spivlifeless: g$timeofday04:40
igctime to hit the review Q04:43
igcif anything is particularly important in there, let me know04:44
DBOyou know what would be great, if bzr was psychic enough to know I was idiotically pushing to the wrong branch...05:00
nDuffDBO, so write a plugin offering mind-reading functionality. It's Python, right? -- there's probably a module for that.05:01
DBOi should... but if we are going to read minds05:02
DBOwe'll have to use lisp05:02
jameshDBO: it'll tell if you're pushing to a diverged branch.  You want something more than that?05:03
DBOjamesh, mostly I am just noting that due to the wonderful way bzr remembers branches (really, I do love it), i often push to the wrong branch after a merge05:04
DBOor when i mean to merge =P05:04
DBOits really just me being stupid and coming to share a bit of feedback with you guys05:05
DBOi do have a real question though05:06
DBOis it launchpad or bzr that is god awfully slow for pushing and pulling?05:06
lifelessDBO: mainly bzr, its getting fixed05:12
DBOlifeless, mind sharing whats going wrong, just for the curious05:13
jmlbtw, I read something on python-dev that said Bazaar was "experimenting" with a time-based release process.05:26
jmlI chuckled a little.05:26
spivjml: we even inhale!05:28
jmlspiv: :D05:28
jameshjml: maybe in a few years we'll find out if it was a worthwhile experiment05:36
vilahi all and happy new year06:58
igchi vila!07:10
spivvila: g'evening.07:12
sorenHow do I change the parent branch url? I used to just do "bzr pull" in one of my local branches, but I've moved the branch on launchpad, and I can't seem to figure out how to get my local branch to cope with that.07:54
spivsoren: "bzr pull --remember NEW_URL"07:55
sorenOf course.07:56
sorenspiv: Thanks!07:56
igcspiv, vila: are you received mailing list emails this afternoon?08:05
igcseems to be blocked somewhere?08:05
vilaigc: hmm, last one seems to date back 7 hours ago...08:06
igcvila: thanks - so it's probably not me or my ISP then. :-)08:06
vilaigc: but I got mail from lp 2 hours ago08:09
* igc dinner08:28
igcnight all08:28
=== kiko is now known as kiko-afk
Keybukerr, why is "bzr shelve" simply throwing away things and not actually shelving them?12:34
Keybukabentley: is bzr shelve broken?12:35
abentleyKeybuk: Not in my experience.12:36
KeybukI do bzr shelve, it puts changes in "id 4"12:36
Keybukthen bzr shelf ls says12:36
KeybukPatches on shelf 'default': None12:36
Keybuk(and then seems to leave the checkout locked)12:37
abentleyThe shelf command is from shelf1, and the shelve command is from shelf2.12:37
abentleyYou want "shelve --list"12:38
Keybukbzr: ERROR: no such option: --list12:38
abentleyAre you sure you said shelve --list, not shelf --list ?12:39
abentleyAh.  --list is in not supported by 1.10.  It'll be in the next release.12:40
Keybukdoes shelve do something different now then?12:40
Keybukwhere does it stash the changes?12:40
abentleyKeybuk: Yes, shelve is much more thorough now.  It stores the changes in .bzr/checkout/shelf12:41
Keybukas patches still, or as a branch?12:41
abentleyKeybuk: as a serialized TreeTransform.12:45
KeybukI'll pretend I understood that so I look smart ;)12:45
abentleyKeybuk: Essentially, as a delta-compressed working tree.12:46
Keybukif you unshelve and there are conflicts, does it still throw the whole thing away? :p12:47
abentleyNo, when you unshelve, it does a merge.12:48
NfNitLoopafter I branched from a svn trunk...15:42
NfNitLoopsomeone had the bright idea of making part of that trunk read-only.15:42
NfNitLoopwhich makes merging back into it... non-trivial.15:42
NfNitLoopThis place does not grok version control.15:43
=== beaumonta is now known as abeaumont
LeoNerdI just did 'bzr shelve' in an svn checkout without realising it, and ... I'm quite surprised it actually works17:01
jelmerLeoNerd, integration ftw (-:17:36
beunojelmer, Loggerhead 1.10 landed in Jaunty. You rock, thanks17:50
* jelmer hugs ubuntu autosync17:51
=== menesis1 is now known as menesis
seb_kuzminskyi think there's a bug in bzr-email19:13
seb_kuzminskyi think it does not honor post_commit_difflimit=0 like the docs say19:14
seb_kuzminskyemailer.py line 11919:14
seb_kuzminskyi get empty commit emails when i set it to 019:14
seb_kuzminskyi'll just set it to 100000 for now19:15
=== menesis1 is now known as menesis
beunopoolie, ping19:45
burak575hi, i made a mistake and a file is corrupted, how can i get last commit of just this file?20:07
beunoburak575, bzr revert -r -1 path/to/file20:08
burak575beuno: thanks i am gona try it :)20:08
burak575it worked thanks again20:09
=== Mario__ is now known as pygi
camason_hi guys. I've been working as a private branch, and I'd like to make this a shared repo. I created a repo with init-repo. How do I now push all of the history of the branch to this repo?20:45
fullermdIs the repo above the branch?20:46
camason_repo is in /srv/bzr/myrepo    project is in /development/projects/myproject20:46
fullermdMmm.  Are you wanting to move your working location over to that new spot?20:47
camason_no I want to keep working in /development, but have that bound to /srv/bzr/myrepo so that I can use that as a centralized repo20:48
camason_I work like that with another project, but its been like that since day one. I'm wanting to move this over20:49
fullermdSo, what you're wanting to have, is a branch in /src/bzr/myrepo/whatever, that you have a checkout of in /dev/projects/whatever.20:49
=== bac is now known as bac_afk
camason_I suppose so. But its a repo created with init-repo20:50
fullermdWell, /srv/bzr/myrepo/project/whatever then; doesn't change anything substantial.20:50
fullermdSo what you need are actually 2 things; first, you need a branch at that new place, and second, you need your old place to become a checkout of it.20:51
fullermdThe first you can do with push; just push the existing branch to the new path.20:51
fullermd(or use 'branch' to do it from outside; either way)20:51
camason_isn't a branch different to a repo?20:51
fullermdYeah, but you've made the repo already, right?20:52
fullermdSo the new branch (whether it be push-made or branch-made) will use it.20:52
fullermdOther than making a repo, you pretty much never do anything that refers directly to it; it's implicit.20:52
camason_well I did bzr push /srv/bzr/myrepo20:53
camason_and bzr status shows that my working area is a checkout of the repo20:53
camason_but the file size of the repo is too small to have any history in it20:54
fullermdWell, it's not technically an error to have a branch colocated with a shared repo, especially if it's no-trees.20:54
fullermdOK, let's back it all up.  Can you pastebin an 'info' output of both locations?20:54
camason_oo i forgot the no-trees bit20:54
fullermdNo big deal.  That just sets a default.20:55
fullermdYou can use 'remove-tree' to whack the WT you don't need.20:55
camason_brb 2 mins going to get on main pc20:56
CaMasonthat's better20:57
CaMasonright so my /srv/bzr/myrepo shows shared repository: . repository branch: .20:59
fullermdSo, yeah.  That's a little unusual maybe, but it's valid.21:00
CaMasoni can just delete this repo and start again21:00
CaMasonI just want a centralised repo that I can access via SFTP from many machines21:00
CaMasonand unbind when I have no interwebs :)21:01
Peng_FWIW, to make a repository no-trees, just touch .bzr/repository/no-working-trees (and for the reverse, delete it)21:11
CaMasonPerhaps someone can explain this workflow to me. In SVN, I would make a repository, and that would contain my branches. So how would I achieve that with bazaar, and what happens when I create / delete branches?21:12
fullermdIn svn, the repository has significant semantic meaning.  In bzr, it doesn't.21:12
CaMasonright, I'm getting confused at the difference between a repository and a branch21:12
fullermdThere's no semantic difference between having 15 standalone branches in /srv/bzr/myproject/, or having a shared repo in /srv/bzr/myproject/ with 15 repo branches.21:13
fullermdIt just saves space and I/O.21:13
CaMasonok, so how does a 'repo branch' differ from a standalone 'branch' ?21:13
=== toytoy_ is now known as toytoy
nDuffCaMason, it stores data in the repository -- and thus doesn't have duplicate data stored between it and any other branch in that repo -- but that's under the hood; from a user perspective they're *exactly* the same21:14
fullermdAll branches have a repository; that's where the revisions are stored.  Standalone branches have their repository internally; repo branches use an external shared repository (which presumably is also being used by other branches)21:14
CaMasonright ok this makes more sense21:15
fullermd(this is a slight lie, because some side effects can leak through the abstraction, but it's near enough that you can ignore them)21:15
CaMasonPerhaps an example would help here. I basically have multiple clients, with multiple projects21:15
CaMasonso I have /srv/bzr/clients/myfirstclient/21:16
CaMasonthen myfirstclient will have multiple projects. So each 'project' would be a shared repository?21:16
fullermdThat would be one way to do it.21:16
nDuffCaMason, so if /srv/bzr is a repository, and you push from the branch at /srv/bzr/clients/myfirstclient/project1 to a server that client owns (for instance), they get only the bits they own..21:16
fullermdAnd probably the best way.21:16
fullermdYou could have one repo for client.  Or one repo for all your clients.  Or one repo for all your bzr stuff.21:17
nDuffCaMason, ...and the above is how I personally would do it, were fullermd (who knows better than me) not advising otherwise.21:17
fullermdOr, the other way, one repo per branch (e.g., a bunch of standalone branches).  There's not necessarily a right way.21:17
fullermdHowever, you probably don't have much (or any) shared code between projects.  So, spanning projects with one repo probably doesn't gain you anything.21:17
CaMasonok. I've probably still got my SVN hat on somewhat21:18
luksone repo for everything is maybe not a good idea for locking reasons21:18
CaMasonno, none of the projects will share any code21:18
luksif multiple users are going to push to that21:18
nDuffCaMason, oh -- if they don't share any code, then there's no need to have shared repos.21:18
fullermdAnd some operations will necessarily scale to the size of the repo, so a single huge repo for everything may have some performance implications.21:18
=== sdboyer is now known as morloch
nDuffCaMason, ...but if you're going to have different branches of any given project, you *will* want to have those branches within the same repo -- makes branching much cheaper (in both space and time)21:18
fullermdI tend to have approximately a repo per project.  It lets me keep things nice and organized.21:18
CaMasonright. So for a particular project, I may want to 'branch' the code off to work on two lines simultaneously21:19
=== morloch is now known as sdboyer
CaMasonso how do I branch that differently to a normal 'branch' procedure?21:19
fullermdHaving a repo per branch (bunch of standalone) wastes a lot of space and I/O.  Having repos spanning projects gains very little, so...21:19
nDuffCaMason, it's just a normal branch, as long as the path you're branching into is under the repo directory.21:19
fullermdNo differently.21:19
CaMasonI see. We're making progress :)21:19
fullermdWhen you make a new branch /some/where, it will look and say "Hm, is there a shared repo at /some/where?  If so, use it.  If not, is there one at /some?  Use it.  If not, is there one at /?"21:20
CaMasonI see :)21:20
fullermdAnd when it runs out of parent dirs to check, and hasn't found one, it makes a standalone branch.21:20
fullermdNow, this means that if you have a branch in a repo at /some/where/repo/branch/, if you move that branch to /some/where/branch/, things will blow up, because it can't find its repo anymore.21:21
fullermdBut if you move it to /some/where/repo/extradir/branchfoo, it'll still work just fine, because it finds the repo at ../../21:21
fullermd(UNLESS you make a repo in extradir too, in which case it'll find that repo, but it doesn't have the revs branchfoo wants, in which case it'll blow up too)21:22
CaMasonmakes sense21:22
fullermdBut you don't tend to run into situations like that, because you hardly ever make one repo inside of another, or move branches in and out of repos with mv.21:22
CaMasonok, does this first part make sense then: http://pastebin.com/m2d6df46021:23
fullermdWhy rich-root?21:23
fullermdsvn conversion?21:23
CaMasonno idea :o I read it somewhere in the docs21:24
CaMasonI don't need it?21:24
fullermdWell, if you don't have need for rich root support, you should probably steer clear of it, just to make everything simpler.21:25
CaMasonok will do :D21:25
fullermdbzr-svn conversions are the main source of need for rich roots ATM.21:25
CaMasonok. ignoring completely21:25
CaMasonso just bzr init-repo --no-trees ?21:25
fullermdOther than that, it looks like a good set of steps.21:25
CaMasonjust another question that may or may not add complication21:26
fullermdAs Peng_ mentioned above, remember that --no-trees or its complement doesn't tie you down forever.  You can remove trees from a branch, or add a tree to the branch, or even [manually, bleh] change the repo's setting.21:26
fullermdIt just gives you the default action.21:26
CaMasonok that's cool21:26
CaMasona 'project' will contain 2 (or more) parts.. the graphics & design, then the php code, then [..others]21:26
fullermd(of course, with a 'central' repo that you don't work directly in, you probably don't want trees anyway, so that would be right)21:27
CaMasonI'd like to version all of that also. So, would you suggest creating the repo under project/ and then having 2..n branches for each of those elements?21:28
CaMasonor would you create a repo for each 'section' of the project? I'm thinking that the design may need to be 'branched', and is not related to the php code21:29
fullermdI'd stick with one repo for the project.21:29
fullermdI think the gains from splitting smaller are tiny, and it just adds management headache.21:29
CaMasonok. and is there any way I could isolate those 3 sections within the repo?21:29
fullermdYou can make extra dirs.21:29
CaMasonwont that matter?21:30
* CaMason takes off his SVN hat21:30
fullermd$REPO/graphics/trunk and $REPO/code/trunk, where the trunk's are both branches, but {graphics,code} are just plain directories.21:30
CaMasonok this is great21:30
fullermdNo, because bzr would check ../, see that it's not a repo, and then check ../../ and find the repo.21:30
fullermd(or any arbitrarily deep nesting if you want)21:30
fullermdHaving the single $REPO also lets you make, say, a $REPO/rewrite/graphics and $REPO/rewrite/code branch pair, if in some usage it's more convenient for them to be direct siblings.21:31
CaMasonso how about managing branches for each of those sections.. say code/branch1 and code/branch221:31
CaMasonsure that makes sense also21:31
fullermdIt's pretty freeform; however makes sense for your project.21:31
fullermdAnd you can rename inside the repo without breaking things; if you had a $REPO/code branch, but decided to change it to $REPO/code/trunk (with code being just a dir), you could do that with mv.21:32
CaMasonI may be speaking at a conference in April about version control benefits, and I'm liking the flexibility of bazaar (even though i've only just started using it)21:32
fullermd(you'd have to update any branches that had the old location saved of course, but...)21:32
CaMasonok, so I branched code/trunk to code/branches/branch1... I made some changes, then I integrated the branch back into the trunk (question for another time). I now have no need for the branch1 working copy to exist, but I'd like to keep the hisrotical data21:33
fullermdIf you merged it into trunk, all the historical data is in trunk's history.21:33
fullermd(merges don't just "roll up" all the changes; they preserve all the historical revisions)21:33
CaMasonso I can rm -rf branches/branch1 ?21:33
fullermdIf it doesn't need to exist independently anymore, yah.21:34
CaMasonor is there something 'tidier' I should do here?21:34
fullermdBranches are basically just pointers into the history, saying "This is my latest revision".21:34
CaMasonno it doesn't need to exist independently, but I'd like to be able to grab a copy of that branch1 at a given state sometime in the future21:34
CaMasonI guess all of that info would be stored in the repo21:35
fullermdSo if that latest revision is merged into another branch, you could recover it from there if you had to (well, branches may have local config that doesn't exist elsewhere, but that doesn't usually matter)21:35
fullermdWell, it doesn't hurt anything to leave branch1 sitting there, so if you expect to have need for it in the future, sure, just let it lie.21:35
CaMasonmakes sense.. but at least I'm not leaving it there for fear of losing the history21:36
fullermdA branch (since the history is all off in the repo) uses something like 8k of disk space.  I doubt it'll bankrupt you.21:36
fullermdAnd remember the mv.  You could mv it to $REPO/code/branches/LEGACY/branch1 or something to "get it out of the way"21:36
CaMasonthat's cool21:36
fullermd(or any other location of your choice; just so long as it's under $REPO)21:37
CaMasonk, so how about this scenario. I have my working copy (bound to my repo on a server somewhere). I now want to make a 'branch' of this trunk. Do I do this on my working copy, or on the repo?21:37
fullermdIt depends on whether it's a branch you want to have in the repo, or just locally.  Either way works fine.21:38
CaMasonit would be a branch to store in the repo21:38
fullermdIf it's a long-lived branch that several people will be working on, you'd probably want that in the repo.21:38
fullermdIf it's something you're going to work on for a few hours, then merge in and be done with, it can be easier to just do it locally.21:38
fullermdI'd say 90% of my branches don't get put in the central repo, because they don't last very long, and I'm the only one working on them while they're alive.21:39
CaMasonok, so if I just want to make a quick branch over lunch to try out a new feature, a local branch would be cool, and then merge back into trunk if it's successful21:39
fullermdAnd if they do turn out to live long and get other people working on them...   well, then, I can just move them into the repo, like you're doing with your trunk right now in this example.21:39
fullermdYah.  The distributed nature of bzr means that a repo isn't a boundary like in svn; moving revisions in and out of and between repos is S.O.P. in bzr.21:40
CaMasonok one last hurdle if you would be so kind21:42
CaMasonI have made a repo under /srv/bzr/clients/myclient21:42
CaMasoni then created myproject/code/trunk within that21:42
CaMasonhow can I then move my current branch (which hasn't lived in a repo yet) to that location?21:43
fullermdWell, you probably want that 'trunk' to be the branch.21:43
fullermdSo `bzr branch $CURRENT_LOCATION /srv/bzr/clients/myclient/myproject/code/trunk`21:43
CaMasonah so I need ot make the 'trunk' a branch21:43
CaMasonI seeeee21:43
fullermdWell, you don't _have_ to.  I just presume that's what you want.21:44
fullermd('branch' doesn't like its destination already existing)21:44
CaMasonyou're right21:44
CaMasonBranched 31 revisions in 1 second, lol21:44
lifelessjelmer: hi21:44
CaMasonnow I should bind my old location to this repo?21:45
fullermdYah, use bind or reconfigure to turn it into a checkout.21:45
CaMason"Tree is up to date at revision 31"21:46
CaMasonlooking goood :D21:47
CaMasonThanks for holding my hand through that fullermd; it's very much appreciated. You've probably saved me hours21:47
fullermdWell, the world has way too few of 'em.  I'm doing my part for the environment   :)21:48
CaMasonI had a great experience in #wordpress the other day... I asked a question to see if there were any recognised patterns for solving this particular problem..21:49
CaMason"Go learn PHP"21:49
fullermdWell, there probably aren't many people here who would dream of saying that   ;)21:50
* fullermd says, as he works on PHP code in a bzr branch...21:51
CaMasonin other news... I got a blue screen of death when trying to use bzr to checkout a branch over SFTP. I was on vista x6421:52
CaMasonBazaar 1.921:52
CaMasonI hadn't tried a branch over SFTP before and I'm too scared to try again :)21:53
* fullermd guesses that "bzr does that sometimes if it detects you're not running ubuntu" wouldn't be a well-received response :p21:54
lifelessCaMason: that suggests a network driver bug to me21:54
lifelessthe check code you got should help diagnose it21:55
lifelessof course, its closed source, so you can't fix it21:55
CaMasonwell I couldn't see any events in my system log either21:55
CaMasonbut I Set the option to prevent vista auto rebooting on a BSOD21:55
fullermdMaybe your OS heard that somebody generated a fake SSL cert, and extrapolated that to a belief that both MD5 and network crypto are totally broken, so it crashed to protect you.21:56
CaMasonsounds about right of MS21:56
CaMasonI'll update my network driver, then update bazaar, then try again21:56
CaMasonalthough I can access SFTP servers without issue using other apps21:57
* CaMason does a huge Windows update21:59
=== bac_afk is now known as bac
jelmerlifeless, moin22:33
pooliehello jelmer, happy new year22:34
jelmerhey Poolie22:34
jelmerthanks, happy new year :-)22:34
lifelesshi jelmer22:36
lifelessso thin packs22:36
lifelesssee git-index-objects - it cannot index a thin pack22:36
jelmerright, dulwich would have to get rid of any ref-delta's during fetch22:37
lifelessit requires --fix-thin to be passed when you invoke it22:37
lifelesssecondly, there is still the question about how git is sure that a external ref in a thin pack is possessed by the client22:37
lifelessdoes it e.g. grab an arbitrary parent tree take that path in that tree and external ref against it?22:38
jelmerlifeless, the delta base can be anything that causes a small delta22:41
jelmeras far as I understand it22:41
lifelessjelmer: well, I've dug deep into this code myself22:42
lifelessbut I haven't got an answer to this yet22:42
lifelessjelmer: it can't be a text the client doesn't have though, by definition22:42
james_wdoesn't it use anything it can infer the client has from what the client told it it had?22:42
jelmerlifeless, sure, but it can be any text that is part of one of the revisions the client has22:43
lifelessyes, but this is something that could be very expensive to determine, if e.g. it tries to reuse the delta22:43
jelmerlifeless, and the server knows what those revisions are (or rather, knows the tips of the revision tree with those revisions)22:43
lifelessor perhaps for that one it doesn't try to reuse22:43
lifelessso let me rephrase my question22:43
lifelessI don't want speculation: I'm totally capable of doing that, I want the algorithm used.22:44
lifeless"one of" is unusably vague for deciding what we can learn from it, unless it really is a random choice22:44
nDuffthe head of client-side development just stepped into my office and indicated he's looking at switching SCMs (right now that side of the company is a p4 shop)22:46
lifelessI'm interested in this to make sure we've learnt as much as possible about what actually makes git fast, vs what people *claim* make it fast22:46
lifelessnDuff: Here's one we prepared earlier!22:46
nDuff...the tricky requirement for them is good integration with Visual Studio.22:47
mamathi, how can i disable bzr-notify from starting up automagically??22:47
nDuffthey have a nontrivial number of win32/.net developers.22:47
lifelessI'm not sure where the current win32 stuff is at, we did have a visual studio soc project a couple years back22:47
jelmermamat, In the GNOME session dialog22:47
jelmerlifeless, This is not speculation, it's based on various things I've read in the git source code / docs / mailing list22:48
mamatjelmer: thx! you just saved 10Mb of my poor ram22:49
aogailHello all.22:53
=== TheMuso_ is now known as TheMuso
aogailI've got a curious problem.22:53
lifelessjelmer: ok, perhaps you can describe it in more detail then: how does it choose which text, and what set are the candidates, and how does it keep that set small or does it not bother keeping it small22:53
jelmerlifeless, have you read /data/jelmer/git/Documentation/technical/pack-heuristics.txt ?22:54
aogailI have a branch that has a changeset whose timestamp is "2008-12-30 13:24:25 -0800". However, when I run "bzr cat -r 'date:2008-12-30 13:24:25'" I get the contents of the file from *before* that change.22:55
fullermdaogail: It stores sub-second resolution, so unless you committed it at 25.000000 seconds...22:55
mtaylorlifeless: http://rafb.net/p/J9b2qs84.html22:56
aogailfullermd: Well, here is the interesting thing: The earliest date I can pass that returns the contents of the file as of the changeset, is '2008-12-31 08:32:32'22:56
fullermdWhich would be the timestamp of the next rev?22:56
lifelessjelmer: /data?22:56
jelmerlifeless, uhm, obviously I mean Documentation/technical/pack-heuristics.txt in the git sources22:57
aogailNo, the timestamp of the next rev is 2008-12-31 10:28:1922:57
jelmer(but yeah, /data - that's unencrypted while /home is encrypted)22:57
fullermdJust go ahead and spoil all my guesses, whydoncha...22:57
lifelessjelmer: yes, and I grok that code22:58
fullermdI'm out of guesses.  I know that date: has in the past been shown to be pretty rough-edged and in need of some smoothing love.  So I'd guess it could well be "something weird about how date: works".22:58
lifelessjelmer: so one possible implementation is that there are a set of external objects available for packing against that are not going to be emitted22:58
lifelessmtaylor: note 't' vs 'T'22:59
mtaylorlifeless: yup22:59
mtaylorlifeless: but it was successful in the first command22:59
lifelessmtaylor: you're on windows?22:59
mtaylorlifeless: no, that's from a friend22:59
lifelessmtaylor: they are on windows22:59
mtaylorlifeless: yes22:59
netdurcan bzr use ftp instead of sftp?22:59
jelmernetdur, yes23:00
* mtaylor doesn't understand that choice, but whatever23:00
lifelessmtaylor: file('foo', 'wt').close(); file('FOO', 'rt').read()23:00
lifelessmtaylor: will work on windows without error23:00
lifelessmtaylor: we're integrating code at the moment to deal with this more gracefully than the current way of just assuming its a unix file system with quirks23:00
mtaylorlifeless: I'm mainly just curious here - but why doesn't the bzr status pick up the file?23:00
Peng_netdur: SFTP is better, of course.23:01
netdurjelmer: thanks23:01
aogailHmm. Well, the reason I'm trying to make this work is that "bzr diff" sticks timestamps in the header rather than revnos -- and the tool I'm using wants to retrieve the full contents of the old version of the file. Is there a way to tell "bzr diff" to put a revno or revid in the diff? (I can modify the tool to work with that instead.)23:01
netdurPeng_: would use sftp if my web host supports it23:01
Peng_netdur: Yell at them about it. :)23:01
lifelessmtaylor: because of two things; firstly the unknown is unknown because its not versioned or ignored in the name with T, which is what the OS reports to listdir()23:02
netdurfor $30 a year? they would just kick me out23:02
mtaylorlifeless: AHA! that makes sense23:02
fullermdaogail: Well, it probably Should(tm) put that info there anyway.  So now all you need is somebody to bug to implement it   :)23:02
lifelessmtaylor: secondly, the file that was added, with the lower case t, is not reported as missing, because it was not present in the basis, its been added-and-missing in the current tree, so you don't see 'missing: ...Test...'23:02
lifelesssorry, missing: ....test...'23:03
lifelessnDuff: perhaps a mail to the list? I know there is interest in good vs integration23:04
lifelessnDuff: or just to me/Martin if you want to keep it low key23:04
aogailfullermd: Heheh, sounds good. Time to start hacking. ;)23:04
jelmerlifeless, so from how I understand it the set of external objects available to delta against is just that set of objects that are part of the revisions the server knows the client has23:07
lifelessjelmer: thats a O(history) set though, so I find the idea of it precalculating that hard to accept, but if it doesn't its expensive to calculate text IN revisions23:10
jelmerlifeless, true23:13
netdurwhen I branch via ftp, will bzr upload everything or just the diff?23:24
netdurhum, am messing things23:25
netdursay, I did branch, then added something new then branched again to the same place23:26
=== edcrypt_ is now known as edcrypt

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