| igc | lifeless, poolie: I'd like to put a patch up for per branch rules again | 00:06 |
|---|---|---|
| igc | I'm thinking of a .bzr/branch/rules file that doesn't propagate | 00:06 |
| igc | ala branch.conf | 00:06 |
| lifeless | so some questions | 00:07 |
| igc | Does that sound ok? | 00:07 |
| lifeless | a) why not put it in branch.conf | 00:07 |
| igc | I'll look into that | 00:08 |
| igc | I suspect formatting might be an issue (but it might not if we agree to allow nested sections) | 00:08 |
| lifeless | and 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 data | 00:08 |
| lifeless | (I honestly prefer new objects every time, but I get the objection folk have to that) | 00:09 |
| fullermd | If it really affects the WT primarily, why put it in .bzr/branch/? | 00:10 |
| lifeless | fullermd: that was my next question :). But I can come up with an immediate use case - checkouts | 00:10 |
| * fullermd doesn't follow. | 00:11 | |
| lifeless | igc: so here is a thing to think about | 00:11 |
| lifeless | igc: consider a loom, or a git-branch-style setup | 00: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 |
| lifeless | igc: 'bzr switch foo' - that will have to backout-gone-and-apply-new rules | 00:12 |
| igc | lifeless: yeah, good point | 00:13 |
| igc | if it were .bzr/checkout/rules, that wouldn't be the case right? | 00:13 |
| lifeless | igc: 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 object | 00:14 |
| lifeless | but the proposed design really started/wanted to treat them as something related to the project - which we have no effective abstraction for | 00:14 |
| lifeless | igc: 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 |
| igc | lifeless: I expect tree-specific rules to override those in .bazaar/rules | 00:16 |
| lifeless | igc: .bazaar/rules is constant for a single invocation though. I was referring to e.g. .bazaar/locations.conf based rules | 00:17 |
| lifeless | (which is another case of trying to allow rules to be included in normal config files0 | 00:17 |
| lifeless | hmm, I didn't mean to sidetrack things | 00:21 |
| lifeless | getting a non-propogating tree-working-with-rules thing that people can use today++ | 00:22 |
| igc | lifeless: 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 |
| lifeless | igc: myself, I have a directory with all my trees for project X | 00:31 |
| === ubott2 is now known as ubottu | ||
| lifeless | igc: so *I* would want, until we have a good answer for 'project' to configure them in locations.conf | 00:31 |
| igc | fullermd: implicitly knowing "the rules" just seemed the bzr way | 00:31 |
| lifeless | igc: its where I configure email settings and default push locations | 00:32 |
| lifeless | igc: which are the other project-wide settings I work with today | 00:32 |
| igc | lifeless: I think we greatly under-utilise locations.conf as a feature of our product | 00:32 |
| fullermd | One way to choose which problem to cause is considering the knock-on effects of each choice. | 00:32 |
| fullermd | Like, 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 |
| lifeless | igc: I agree we want to end up with just knowing the rules, as much as possible | 00:34 |
| igc | from 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 |
| lifeless | lunchtime, got some chores to run too, back in a bit | 00:35 |
| === Mario__ is now known as pygi | ||
| igc | fullermd: yes | 00:39 |
| jml | remind me, how do you change the branch location of a working tree? | 00:42 |
| jml | say you've renamed the branch and want the tree to point to the new location | 00:42 |
| spiv | jml: "bzr switch" maybe? | 00:43 |
| jml | spiv: it raises errors about the old branch not existing | 00:43 |
| spiv | Hmm, I thought I saw patches about that bug a while back. | 00:43 |
| spiv | The crappy way is to edit .bzr/checkout/something | 00:44 |
| igc | Hmm - I'm talking crap. My nested sections stuff was related to defining shell hooks, not rules, it seems | 00:44 |
| jml | spiv: there doesn't seem to be a reconfigure either. | 00:45 |
| jamesh | perhaps 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? :P | 00:47 | |
| Peng_ | /renamed/whatever | 00:47 |
| fullermd | Oh, heck, not even a year ago. | 00:49 |
| jml | spiv: I filed https://bugs.edge.launchpad.net/bzr/+bug/313898 | 00:50 |
| ubottu | Error: <Bugtracker.plugin.Launchpad instance at 0x865470c> bug 313898 not found | 00:50 |
| fullermd | Try bug 285055 and bug 308798 | 00:51 |
| ubottu | Launchpad bug 285055 in bzr "switch --force on lightweight checkout connects to original remote branch" [Medium,Fix committed] https://launchpad.net/bugs/285055 | 00:51 |
| ubottu | Launchpad bug 308798 in bzr "Unable to switch lightweight checkout when it's parent branch is renamed" [Undecided,New] https://launchpad.net/bugs/308798 | 00:51 |
| spiv | jml: thanks | 00:54 |
| === Mario__ is now known as pygi | ||
| igc | abentley: can you bounce BB please if you're around? | 01:05 |
| jml | how 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 |
| beuno | jml, it would make me cry of joy | 01:15 |
| AfC | jml: we don't use Launchpad, so I wouldn't notice. | 01:16 |
| jml | cool. I'll file a bug and say I'll mentor it (and maybe jfdi later) | 01:17 |
| jml | beuno: https://bugs.edge.launchpad.net/bzr/+bug/313916 | 01:21 |
| ubottu | Ubuntu bug 313916 in bzr "Command to open a branch's web page in Launchpad" [Undecided,New] | 01:21 |
| AfC | jml: 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 |
| jml | AfC: yeah, I mention that on the bug. | 01:23 |
| AfC | jml: 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 |
| jml | AfC: the bug metadata is already there... it just has lousy APIs and not much in the way of command line access | 01:25 |
| AfC | jml: I would define that as "not actually there" then, but {shrug} | 01:26 |
| jml | (o for a thousand days to hack) | 01:26 |
| AfC | indeed | 01:26 |
| AfC | but 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 lunch | 02:05 | |
| rockstar | If 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 |
| lifeless | rockstar: 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 again | 02:16 |
| rockstar | lifeless, I can't because the file doesn't exist... | 02:16 |
| lifeless | rockstar: bzr st | 02:16 |
| rockstar | Ah, bzr resolve <path/to/file> worked. | 02:16 |
| rockstar | Path conflict: <deleted> / tools/run_debug.py | 02:16 |
| rockstar | lifeless, ^^ | 02:17 |
| === Mario__ is now known as pygi | ||
| === Mario__ is now known as pygi | ||
| lifeless | markh: btw with bugs | 02:38 |
| lifeless | markh: you don't need to make things invalid on bzr, you can just edit the task to say its for bzr-gtk only | 02:39 |
| === TheMuso_ is now known as TheMuso | ||
| lifeless | spiv: ping | 03:31 |
| spiv | lifeless: pong | 03:33 |
| lifeless | brisbane core has some networking implications | 03:34 |
| lifeless | do you have a branch working on generating a stream | 03:35 |
| lifeless | for push and pull | 03:35 |
| spiv | I do, for push. | 03:35 |
| spiv | http://people.ubuntu.com/~andrew/bzr/streaming-push (it's a loom) | 03:35 |
| lifeless | cool | 03:36 |
| lifeless | are there docs on the wire format you're putting together? I'd like to collaborate on that early | 03:36 |
| lifeless | also, have you looked at what git does to determine the objects to include in its wire transfers? | 03:37 |
| spiv | lifeless: hmm, no docs yet, although it's still in flux a bit. | 03:42 |
| spiv | lifeless: it's more-or-less a series of bencoded tuples of the attributes of the ContentFactory objects returned by get_record_stream | 03:43 |
| spiv | And 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 |
| lifeless | ok, well to figure out anything git does I've found reading the source the best way | 03:44 |
| spiv | I don't suppose you have a bzr mirror of the git source handy? ;) | 03:44 |
| lifeless | nope | 03:45 |
| lifeless | what about the actual delta content | 03:46 |
| lifeless | uhm | 03:46 |
| * jelmer has enough knowledge about the git wire protocol now that he's implemneted it :-) | 03:46 | |
| lifeless | let me be more precise in a couple of ways | 03:46 |
| lifeless | jelmer: what I want is the algorithm for determining objects-to-include and objects-we-can-use-deltas-against | 03:46 |
| spiv | jelmer: I take you used the source to learn about it? | 03:46 |
| lifeless | jelmer: if you could write that up that would be great | 03:46 |
| jelmer | lifeless, that's two different processes | 03:47 |
| jelmer | basically what happens is: | 03:47 |
| lifeless | jelmer: things like is it chatty, does it assume cheap heads-lists, does it use the reflogs and so on | 03:47 |
| jelmer | -> server sends list of HEADs it has | 03:47 |
| jelmer | <- client sends "want <rev>" for each <rev> it wants to end up with | 03:47 |
| lifeless | jelmer: this is push or pull use case? | 03:47 |
| lifeless | jelmer: also is this full duplex or back and forth on each item | 03:48 |
| jelmer | then the client starts sending "have <rev>" for the ancestors of its local heads, until the server confirms it has one of those revisions | 03:48 |
| jelmer | lifeless, this is pull | 03:48 |
| jelmer | lifeless, it's full duplex | 03:48 |
| jelmer | so 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 revision | 03:49 |
| lifeless | breadth first traversal I presume | 03:49 |
| jelmer | yup | 03:49 |
| jelmer | after this process, the server sends the complete contents of a .pack file that can be written to disk immediately | 03:50 |
| lifeless | and it does this per-local-head or all-in-parallel? if its all-in-parallel, does it trim when a particular head is reached | 03:50 |
| lifeless | or just keep going until all have had revs reached | 03:50 |
| lifeless | or until any-rev is reached? | 03:51 |
| lifeless | [I can rephrase this as - whats the algorithm, as opposed to the mechanics:P] | 03:51 |
| jelmer | all-in-parallel | 03:51 |
| jelmer | it obviously stops sending "have <rev>" for the ancestors of a particular head as soon as the server has confirmed it knows about a particular head | 03:52 |
| jelmer | it 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 head | 03:52 |
| lifeless | doesn't it need to know all ancestors? I mean, consider a:[b,c] | 03:52 |
| lifeless | if the server says it knows b, and we want a (but don't have a) that doesn't imply that the server has c | 03:53 |
| lifeless | erm bad example. a:[b,c], b:[d,e] | 03:53 |
| jelmer | yes, it needs to know all ancestors | 03:53 |
| lifeless | want: a | 03:53 |
| lifeless | anyhow, this is not surprising, its what I thought it did :) | 03:54 |
| lifeless | the key differences to bzr are server-state-is-accrued and full-duplex | 03:55 |
| jelmer | yeah, it's not rocket science but it is a really fast protocol | 03:56 |
| lifeless | these are only rev ids though right, it doesn't recurse into dir objects at this stage | 03:56 |
| lifeless | it infers those when building the pack | 03:57 |
| lifeless | ? | 03:57 |
| jelmer | lifeless, yes | 03:57 |
| jelmer | lifeless, same for what to delta against what | 03:57 |
| lifeless | secondly, I thought git had thin packs for pull and push | 03:57 |
| jelmer | what are thin packs supposed to be? | 03:57 |
| lifeless | which were *not* written verbatim to disk but instead expanded to meet the normal assertions about pack content | 03:57 |
| lifeless | they are packs which have deltas external to the pack | 03:57 |
| jelmer | lifeless, ah, right | 03:58 |
| jelmer | lifeless, but at least as far as I can tell, those can exist in regular git packs as well | 03:58 |
| jelmer | and if not, we have a dulwich bug :-) | 03:58 |
| lifeless | oh also the HEADS list is something we try not to do, because that list can be _big_ | 03:58 |
| lifeless | no, they are not meant to exist in regular git packs | 03:58 |
| jelmer | lifeless: sorry, it's the list of refs in the case of git, not the list of heads | 04:00 |
| jelmer | I 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 |
| lifeless | jelmer: ah goo | 04:00 |
| lifeless | *good* | 04:00 |
| lifeless | so thats name:revid? | 04:01 |
| jelmer | basically, yeah | 04:01 |
| lifeless | ok | 04:01 |
| lifeless | spiv: back to our discussion | 04:01 |
| jelmer | hth | 04:01 |
| lifeless | jelmer: it was useful | 04:01 |
| lifeless | jelmer: still not clear on the logic for whats assumed held by the client for thin packs | 04:01 |
| jelmer | lifeless, what do you mean with held by the client? | 04:02 |
| jelmer | lifeless, what sha1-objects are held by the client? | 04:02 |
| lifeless | jelmer: 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 |
| spiv | lifeless: 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 |
| spiv | lifeless: jam has asked that I add the compression parent to that, for obvious reasons. | 04:03 |
| jelmer | lifeless, "alternate A"? | 04:04 |
| jelmer | lifeless, there is no such thing as ghosts | 04:04 |
| lifeless | jelmer: look up git alternates - stacked repos | 04:04 |
| lifeless | spiv: well compression information should be specific to the compressor | 04:05 |
| spiv | Right, that would be ideal. | 04:05 |
| lifeless | I think you should refresh your memory of http://www.kernel.org/pub/software/scm/git/docs/technical/pack-format.txt at some point soon | 04:06 |
| lifeless | just as a reference | 04:07 |
| lifeless | e.g. we don't need the sha1 in this stream, its dead space. We can sha the entire stream for integrity checking | 04:07 |
| lifeless | what are the build details? | 04:08 |
| spiv | record._build_details for 'knit-*' records, otherwise blank (signified by an empty tuple). | 04:09 |
| lifeless | spiv: have you looked at group compress | 04:10 |
| spiv | Not recently. It's probably about time I refreshed my memory. | 04:10 |
| lifeless | ok | 04:10 |
| lifeless | basically | 04:10 |
| jelmer | lifeless: As far as I can tell there's no particular special-casing for alternates so that would indeed require another network op | 04:10 |
| lifeless | label: | 04:10 |
| lifeless | sha1: | 04:10 |
| lifeless | CONTENT | 04:11 |
| lifeless | rinse and repeat, thats the entire format | 04:11 |
| jelmer | lifeless, not entirely, the delta'ed entries don't have a sha1 | 04:11 |
| spiv | Basically 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 |
| lifeless | it will not fit at all well into what you seem to be proposing | 04:12 |
| lifeless | spiv: yeah, thats what we did last time, and why I want to engage on this early ;) | 04:12 |
| jelmer | nm, I thought you meant the separate entries | 04:14 |
| * jelmer gets some sleep | 04:14 | |
| lifeless | first 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 |
| lifeless | but that would allow a number of group compress streams to be embedded | 04:15 |
| spiv | So, which things are constant for all records, and which can vary? | 04:15 |
| lifeless | each of which contain N actual texts | 04:16 |
| spiv | (key, sha1, record_kind), and everything else depends on record_kind? | 04:16 |
| lifeless | nope, a step up | 04:16 |
| lifeless | stream = [substream ...] | 04:16 |
| lifeless | substream = gcstream | knitstream | weavestream | 04:17 |
| lifeless | knitstream = [bencode tuple ...] | 04:17 |
| lifeless | gcstream = to be discussed (does it support parent meta-data, or is that forced up a level, etc) | 04:18 |
| lifeless | weavestream = a weave verbatim | 04:18 |
| spiv | Ok, although that doesn't fit 100% neatly with the get_record_stream API. | 04:18 |
| lifeless | it should fit perfectly | 04: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 |
| spiv | Ok. | 04:21 |
| spiv | I was thinking about stacking, but I guess that's handled by the caller of the repo(s), not the repo itself. | 04:22 |
| lifeless | that was one of the problems with the prior network stream - it was setup to fit the knit api | 04:22 |
| lifeless | but the knit api was random access and quirky | 04:22 |
| lifeless | I'm not sure how stacking fits in here | 04:23 |
| jml | is there a way to do 'bzr log -r(tag:foo+1)..' | 04:25 |
| lifeless | after:/ | 04:25 |
| lifeless | ? | 04:25 |
| lifeless | dunno | 04:25 |
| lifeless | spiv: so the fact there are knitstreams as subelements wouldn't be exposed by the api | 04:26 |
| jml | nope | 04:26 |
| spiv | There's no "after:" rev spec. There's before:, but that's easier to define. | 04:26 |
| spiv | I guess after: might be well-defined in the context of a particular branch. | 04:27 |
| lifeless | spiv: 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 us | 04:28 |
| spiv | lifeless: 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 |
| lifeless | spiv: which is supported by the record stream API (None for sha1) | 04:28 |
| spiv | Probably you just peek at the first record to figure out what sort of (sub)stream to serialise. | 04:28 |
| lifeless | well | 04:29 |
| lifeless | a stream->bytes adapter would be nice | 04:29 |
| lifeless | I imagine it would start with an empty output stream | 04:29 |
| lifeless | then 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 weave | 04:30 |
| lifeless | [though weaves are a bad example because they just generate FullTextContentFactory objects, as I wanted 'works' not 'optimal' | 04:31 |
| lifeless | ] | 04:31 |
| lifeless | git-pack-records, for reference, holds a little metadata about every object, then decides based on that how to retrieve it and how to include it | 04:31 |
| lifeless | (e.g. to just copy it, or to extract and redelta, etc) | 04:32 |
| lifeless | concrete example though, in gc, record.get_bytes_as(record.storage_kind) -> nonsense-data | 04:33 |
| lifeless | so, I started at 730 this morning, I'm going to call it now ;) | 04:39 |
| lifeless | gnight poolie spiv igc jelmer etc etc etc | 04:39 |
| igc | night lifeless | 04:39 |
| spiv | lifeless: g$timeofday | 04:40 |
| igc | time to hit the review Q | 04:43 |
| igc | if anything is particularly important in there, let me know | 04:44 |
| DBO | you know what would be great, if bzr was psychic enough to know I was idiotically pushing to the wrong branch... | 05:00 |
| nDuff | DBO, so write a plugin offering mind-reading functionality. It's Python, right? -- there's probably a module for that. | 05:01 |
| DBO | yeah... | 05:02 |
| DBO | i should... but if we are going to read minds | 05:02 |
| DBO | we'll have to use lisp | 05:02 |
| jamesh | DBO: it'll tell if you're pushing to a diverged branch. You want something more than that? | 05:03 |
| DBO | jamesh, 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 merge | 05:04 |
| DBO | or when i mean to merge =P | 05:04 |
| DBO | its really just me being stupid and coming to share a bit of feedback with you guys | 05:05 |
| DBO | i do have a real question though | 05:06 |
| DBO | is it launchpad or bzr that is god awfully slow for pushing and pulling? | 05:06 |
| lifeless | DBO: mainly bzr, its getting fixed | 05:12 |
| DBO | lifeless, mind sharing whats going wrong, just for the curious | 05:13 |
| jml | btw, I read something on python-dev that said Bazaar was "experimenting" with a time-based release process. | 05:26 |
| jml | I chuckled a little. | 05:26 |
| spiv | jml: we even inhale! | 05:28 |
| jml | spiv: :D | 05:28 |
| jamesh | jml: maybe in a few years we'll find out if it was a worthwhile experiment | 05:36 |
| vila | hi all and happy new year | 06:58 |
| igc | hi vila! | 07:10 |
| spiv | vila: g'evening. | 07:12 |
| soren | How 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 |
| spiv | soren: "bzr pull --remember NEW_URL" | 07:55 |
| soren | *facepalm* | 07:56 |
| soren | Of course. | 07:56 |
| soren | spiv: Thanks! | 07:56 |
| igc | spiv, vila: are you received mailing list emails this afternoon? | 08:05 |
| igc | seems to be blocked somewhere? | 08:05 |
| vila | igc: hmm, last one seems to date back 7 hours ago... | 08:06 |
| igc | vila: thanks - so it's probably not me or my ISP then. :-) | 08:06 |
| vila | igc: but I got mail from lp 2 hours ago | 08:09 |
| * igc dinner | 08:28 | |
| igc | night all | 08:28 |
| === kiko is now known as kiko-afk | ||
| Keybuk | err, why is "bzr shelve" simply throwing away things and not actually shelving them? | 12:34 |
| Keybuk | abentley: is bzr shelve broken? | 12:35 |
| abentley | Keybuk: Not in my experience. | 12:36 |
| Keybuk | I do bzr shelve, it puts changes in "id 4" | 12:36 |
| Keybuk | then bzr shelf ls says | 12:36 |
| Keybuk | Patches on shelf 'default': None | 12:36 |
| Keybuk | (and then seems to leave the checkout locked) | 12:37 |
| Keybuk | bzr1.10-1~bazaar1~intrepid1 | 12:37 |
| Keybuk | bzrtools1.10-1~bazaar1~intrepid1 | 12:37 |
| abentley | The shelf command is from shelf1, and the shelve command is from shelf2. | 12:37 |
| Keybuk | err? | 12:38 |
| abentley | You want "shelve --list" | 12:38 |
| Keybuk | bzr: ERROR: no such option: --list | 12:38 |
| abentley | Are you sure you said shelve --list, not shelf --list ? | 12:39 |
| Keybuk | yup | 12:39 |
| abentley | Ah. --list is in not supported by 1.10. It'll be in the next release. | 12:40 |
| Keybuk | does shelve do something different now then? | 12:40 |
| Keybuk | where does it stash the changes? | 12:40 |
| abentley | Keybuk: Yes, shelve is much more thorough now. It stores the changes in .bzr/checkout/shelf | 12:41 |
| Keybuk | as patches still, or as a branch? | 12:41 |
| abentley | Keybuk: as a serialized TreeTransform. | 12:45 |
| Keybuk | I'll pretend I understood that so I look smart ;) | 12:45 |
| abentley | Keybuk: Essentially, as a delta-compressed working tree. | 12:46 |
| Keybuk | if you unshelve and there are conflicts, does it still throw the whole thing away? :p | 12:47 |
| abentley | No, when you unshelve, it does a merge. | 12:48 |
| abentley | bbl | 12:48 |
| Keybuk | \o/ | 12:50 |
| NfNitLoop | *sigh* | 15:42 |
| NfNitLoop | after I branched from a svn trunk... | 15:42 |
| NfNitLoop | someone had the bright idea of making part of that trunk read-only. | 15:42 |
| NfNitLoop | which makes merging back into it... non-trivial. | 15:42 |
| NfNitLoop | This place does not grok version control. | 15:43 |
| === beaumonta is now known as abeaumont | ||
| LeoNerd | I just did 'bzr shelve' in an svn checkout without realising it, and ... I'm quite surprised it actually works | 17:01 |
| jelmer | LeoNerd, integration ftw (-: | 17:36 |
| LeoNerd | indeed | 17:37 |
| beuno | jelmer, Loggerhead 1.10 landed in Jaunty. You rock, thanks | 17:50 |
| * jelmer hugs ubuntu autosync | 17:51 | |
| === menesis1 is now known as menesis | ||
| seb_kuzminsky | i think there's a bug in bzr-email | 19:13 |
| seb_kuzminsky | i think it does not honor post_commit_difflimit=0 like the docs say | 19:14 |
| seb_kuzminsky | emailer.py line 119 | 19:14 |
| seb_kuzminsky | i get empty commit emails when i set it to 0 | 19:14 |
| seb_kuzminsky | i'll just set it to 100000 for now | 19:15 |
| === menesis1 is now known as menesis | ||
| beuno | poolie, ping | 19:45 |
| burak575 | hi, i made a mistake and a file is corrupted, how can i get last commit of just this file? | 20:07 |
| beuno | burak575, bzr revert -r -1 path/to/file | 20:08 |
| burak575 | beuno: thanks i am gona try it :) | 20:08 |
| burak575 | it worked thanks again | 20:09 |
| beuno | np | 20: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 |
| fullermd | Is the repo above the branch? | 20:46 |
| camason_ | repo is in /srv/bzr/myrepo project is in /development/projects/myproject | 20:46 |
| fullermd | Mmm. 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 repo | 20:48 |
| camason_ | I work like that with another project, but its been like that since day one. I'm wanting to move this over | 20:49 |
| fullermd | So, 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-repo | 20:50 |
| fullermd | Well, /srv/bzr/myrepo/project/whatever then; doesn't change anything substantial. | 20:50 |
| fullermd | So 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 |
| fullermd | The 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 |
| fullermd | Yeah, but you've made the repo already, right? | 20:52 |
| camason_ | yeah | 20:52 |
| fullermd | So the new branch (whether it be push-made or branch-made) will use it. | 20:52 |
| fullermd | Other 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/myrepo | 20:53 |
| camason_ | and bzr status shows that my working area is a checkout of the repo | 20:53 |
| camason_ | but the file size of the repo is too small to have any history in it | 20:54 |
| fullermd | Well, it's not technically an error to have a branch colocated with a shared repo, especially if it's no-trees. | 20:54 |
| fullermd | OK, let's back it all up. Can you pastebin an 'info' output of both locations? | 20:54 |
| camason_ | oo i forgot the no-trees bit | 20:54 |
| fullermd | No big deal. That just sets a default. | 20:55 |
| fullermd | You can use 'remove-tree' to whack the WT you don't need. | 20:55 |
| camason_ | brb 2 mins going to get on main pc | 20:56 |
| CaMason | that's better | 20:57 |
| CaMason | right so my /srv/bzr/myrepo shows shared repository: . repository branch: . | 20:59 |
| fullermd | So, yeah. That's a little unusual maybe, but it's valid. | 21:00 |
| CaMason | i can just delete this repo and start again | 21:00 |
| CaMason | I just want a centralised repo that I can access via SFTP from many machines | 21:00 |
| CaMason | and 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 |
| CaMason | Perhaps 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 |
| fullermd | In svn, the repository has significant semantic meaning. In bzr, it doesn't. | 21:12 |
| CaMason | right, I'm getting confused at the difference between a repository and a branch | 21:12 |
| fullermd | There'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 |
| fullermd | It just saves space and I/O. | 21:13 |
| CaMason | ok, so how does a 'repo branch' differ from a standalone 'branch' ? | 21:13 |
| === toytoy_ is now known as toytoy | ||
| nDuff | CaMason, 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 same | 21:14 |
| fullermd | All 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 |
| CaMason | right ok this makes more sense | 21: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 |
| CaMason | Perhaps an example would help here. I basically have multiple clients, with multiple projects | 21:15 |
| CaMason | so I have /srv/bzr/clients/myfirstclient/ | 21:16 |
| CaMason | then myfirstclient will have multiple projects. So each 'project' would be a shared repository? | 21:16 |
| fullermd | That would be one way to do it. | 21:16 |
| nDuff | CaMason, 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 |
| fullermd | And probably the best way. | 21:16 |
| fullermd | You could have one repo for client. Or one repo for all your clients. Or one repo for all your bzr stuff. | 21:17 |
| nDuff | CaMason, ...and the above is how I personally would do it, were fullermd (who knows better than me) not advising otherwise. | 21:17 |
| fullermd | Or, the other way, one repo per branch (e.g., a bunch of standalone branches). There's not necessarily a right way. | 21:17 |
| fullermd | However, 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 |
| CaMason | ok. I've probably still got my SVN hat on somewhat | 21:18 |
| luks | one repo for everything is maybe not a good idea for locking reasons | 21:18 |
| CaMason | no, none of the projects will share any code | 21:18 |
| luks | if multiple users are going to push to that | 21:18 |
| nDuff | CaMason, oh -- if they don't share any code, then there's no need to have shared repos. | 21:18 |
| fullermd | And 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 | ||
| nDuff | CaMason, ...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 |
| fullermd | I tend to have approximately a repo per project. It lets me keep things nice and organized. | 21:18 |
| CaMason | right. So for a particular project, I may want to 'branch' the code off to work on two lines simultaneously | 21:19 |
| === morloch is now known as sdboyer | ||
| CaMason | so how do I branch that differently to a normal 'branch' procedure? | 21:19 |
| fullermd | Having 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 |
| nDuff | CaMason, it's just a normal branch, as long as the path you're branching into is under the repo directory. | 21:19 |
| fullermd | No differently. | 21:19 |
| CaMason | I see. We're making progress :) | 21:19 |
| fullermd | When 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 |
| CaMason | I see :) | 21:20 |
| fullermd | And when it runs out of parent dirs to check, and hasn't found one, it makes a standalone branch. | 21:20 |
| fullermd | Now, 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 |
| CaMason | right | 21:21 |
| fullermd | But 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 |
| CaMason | makes sense | 21:22 |
| fullermd | But 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 |
| CaMason | ok, does this first part make sense then: http://pastebin.com/m2d6df460 | 21:23 |
| fullermd | Why rich-root? | 21:23 |
| fullermd | svn conversion? | 21:23 |
| CaMason | no idea :o I read it somewhere in the docs | 21:24 |
| CaMason | I don't need it? | 21:24 |
| fullermd | Well, if you don't have need for rich root support, you should probably steer clear of it, just to make everything simpler. | 21:25 |
| CaMason | ok will do :D | 21:25 |
| fullermd | bzr-svn conversions are the main source of need for rich roots ATM. | 21:25 |
| CaMason | ok. ignoring completely | 21:25 |
| CaMason | so just bzr init-repo --no-trees ? | 21:25 |
| fullermd | Other than that, it looks like a good set of steps. | 21:25 |
| CaMason | just another question that may or may not add complication | 21:26 |
| fullermd | As 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 |
| fullermd | It just gives you the default action. | 21:26 |
| CaMason | ok that's cool | 21:26 |
| CaMason | a '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 |
| CaMason | I'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 |
| CaMason | or 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 code | 21:29 |
| fullermd | I'd stick with one repo for the project. | 21:29 |
| fullermd | I think the gains from splitting smaller are tiny, and it just adds management headache. | 21:29 |
| CaMason | ok. and is there any way I could isolate those 3 sections within the repo? | 21:29 |
| fullermd | You can make extra dirs. | 21:29 |
| CaMason | wont that matter? | 21:30 |
| * CaMason takes off his SVN hat | 21: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 |
| CaMason | ok this is great | 21:30 |
| fullermd | No, 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 |
| fullermd | Having 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 |
| CaMason | so how about managing branches for each of those sections.. say code/branch1 and code/branch2 | 21:31 |
| CaMason | sure that makes sense also | 21:31 |
| fullermd | It's pretty freeform; however makes sense for your project. | 21:31 |
| fullermd | And 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 |
| CaMason | I 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 |
| CaMason | ok, 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 data | 21:33 |
| fullermd | If 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 |
| CaMason | so I can rm -rf branches/branch1 ? | 21:33 |
| fullermd | If it doesn't need to exist independently anymore, yah. | 21:34 |
| CaMason | or is there something 'tidier' I should do here? | 21:34 |
| fullermd | Branches are basically just pointers into the history, saying "This is my latest revision". | 21:34 |
| CaMason | no 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 future | 21:34 |
| CaMason | I guess all of that info would be stored in the repo | 21:35 |
| fullermd | So 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 |
| fullermd | Well, 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 |
| CaMason | makes sense.. but at least I'm not leaving it there for fear of losing the history | 21:36 |
| fullermd | A 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 |
| fullermd | And remember the mv. You could mv it to $REPO/code/branches/LEGACY/branch1 or something to "get it out of the way" | 21:36 |
| CaMason | that's cool | 21:36 |
| fullermd | (or any other location of your choice; just so long as it's under $REPO) | 21:37 |
| CaMason | k, 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 |
| fullermd | It depends on whether it's a branch you want to have in the repo, or just locally. Either way works fine. | 21:38 |
| CaMason | it would be a branch to store in the repo | 21:38 |
| fullermd | If it's a long-lived branch that several people will be working on, you'd probably want that in the repo. | 21:38 |
| fullermd | If 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 |
| fullermd | I'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 |
| CaMason | ok, 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 successful | 21:39 |
| fullermd | And 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 |
| fullermd | Yah. 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 |
| CaMason | ok one last hurdle if you would be so kind | 21:42 |
| CaMason | I have made a repo under /srv/bzr/clients/myclient | 21:42 |
| CaMason | i then created myproject/code/trunk within that | 21:42 |
| CaMason | how can I then move my current branch (which hasn't lived in a repo yet) to that location? | 21:43 |
| fullermd | Well, you probably want that 'trunk' to be the branch. | 21:43 |
| fullermd | So `bzr branch $CURRENT_LOCATION /srv/bzr/clients/myclient/myproject/code/trunk` | 21:43 |
| CaMason | ah so I need ot make the 'trunk' a branch | 21:43 |
| CaMason | I seeeee | 21:43 |
| fullermd | Well, 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 |
| CaMason | you're right | 21:44 |
| CaMason | Branched 31 revisions in 1 second, lol | 21:44 |
| lifeless | jelmer: hi | 21:44 |
| CaMason | now I should bind my old location to this repo? | 21:45 |
| fullermd | Yah, use bind or reconfigure to turn it into a checkout. | 21:45 |
| CaMason | "Tree is up to date at revision 31" | 21:46 |
| CaMason | looking goood :D | 21:47 |
| CaMason | Thanks for holding my hand through that fullermd; it's very much appreciated. You've probably saved me hours | 21:47 |
| fullermd | Well, the world has way too few of 'em. I'm doing my part for the environment :) | 21:48 |
| CaMason | I 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 |
| fullermd | Well, 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 | |
| CaMason | in other news... I got a blue screen of death when trying to use bzr to checkout a branch over SFTP. I was on vista x64 | 21:52 |
| CaMason | Bazaar 1.9 | 21:52 |
| CaMason | I 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 :p | 21:54 | |
| lifeless | CaMason: that suggests a network driver bug to me | 21:54 |
| CaMason | :o | 21:54 |
| lifeless | the check code you got should help diagnose it | 21:55 |
| lifeless | of course, its closed source, so you can't fix it | 21:55 |
| lifeless | :) | 21:55 |
| CaMason | well I couldn't see any events in my system log either | 21:55 |
| CaMason | but I Set the option to prevent vista auto rebooting on a BSOD | 21:55 |
| fullermd | Maybe 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 |
| CaMason | sounds about right of MS | 21:56 |
| CaMason | I'll update my network driver, then update bazaar, then try again | 21:56 |
| poolie | hello | 21:56 |
| CaMason | although I can access SFTP servers without issue using other apps | 21:57 |
| * CaMason does a huge Windows update | 21:59 | |
| === bac_afk is now known as bac | ||
| jelmer | lifeless, moin | 22:33 |
| poolie | hello jelmer, happy new year | 22:34 |
| jelmer | hey Poolie | 22:34 |
| jelmer | thanks, happy new year :-) | 22:34 |
| lifeless | hi jelmer | 22:36 |
| lifeless | so thin packs | 22:36 |
| lifeless | see git-index-objects - it cannot index a thin pack | 22:36 |
| jelmer | right, dulwich would have to get rid of any ref-delta's during fetch | 22:37 |
| lifeless | it requires --fix-thin to be passed when you invoke it | 22:37 |
| lifeless | secondly, there is still the question about how git is sure that a external ref in a thin pack is possessed by the client | 22:37 |
| lifeless | does it e.g. grab an arbitrary parent tree take that path in that tree and external ref against it? | 22:38 |
| jelmer | lifeless, the delta base can be anything that causes a small delta | 22:41 |
| jelmer | as far as I understand it | 22:41 |
| lifeless | jelmer: well, I've dug deep into this code myself | 22:42 |
| lifeless | but I haven't got an answer to this yet | 22:42 |
| lifeless | jelmer: it can't be a text the client doesn't have though, by definition | 22:42 |
| james_w | doesn't it use anything it can infer the client has from what the client told it it had? | 22:42 |
| jelmer | lifeless, sure, but it can be any text that is part of one of the revisions the client has | 22:43 |
| lifeless | yes, but this is something that could be very expensive to determine, if e.g. it tries to reuse the delta | 22:43 |
| jelmer | lifeless, and the server knows what those revisions are (or rather, knows the tips of the revision tree with those revisions) | 22:43 |
| lifeless | or perhaps for that one it doesn't try to reuse | 22:43 |
| lifeless | so let me rephrase my question | 22:43 |
| lifeless | I 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 choice | 22:44 |
| nDuff | hmm | 22:46 |
| nDuff | the 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 |
| lifeless | I'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 fast | 22:46 |
| lifeless | nDuff: Here's one we prepared earlier! | 22:46 |
| nDuff | ...the tricky requirement for them is good integration with Visual Studio. | 22:47 |
| mamat | hi, how can i disable bzr-notify from starting up automagically?? | 22:47 |
| nDuff | they have a nontrivial number of win32/.net developers. | 22:47 |
| lifeless | I'm not sure where the current win32 stuff is at, we did have a visual studio soc project a couple years back | 22:47 |
| jelmer | mamat, In the GNOME session dialog | 22:47 |
| jelmer | lifeless, This is not speculation, it's based on various things I've read in the git source code / docs / mailing list | 22:48 |
| mamat | jelmer: thx! you just saved 10Mb of my poor ram | 22:49 |
| aogail | Hello all. | 22:53 |
| === TheMuso_ is now known as TheMuso | ||
| aogail | I've got a curious problem. | 22:53 |
| lifeless | jelmer: 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 small | 22:53 |
| jelmer | lifeless, have you read /data/jelmer/git/Documentation/technical/pack-heuristics.txt ? | 22:54 |
| aogail | I 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 |
| fullermd | aogail: It stores sub-second resolution, so unless you committed it at 25.000000 seconds... | 22:55 |
| mtaylor | lifeless: http://rafb.net/p/J9b2qs84.html | 22:56 |
| aogail | fullermd: 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 |
| fullermd | Which would be the timestamp of the next rev? | 22:56 |
| lifeless | jelmer: /data? | 22:56 |
| jelmer | lifeless, uhm, obviously I mean Documentation/technical/pack-heuristics.txt in the git sources | 22:57 |
| aogail | No, the timestamp of the next rev is 2008-12-31 10:28:19 | 22:57 |
| jelmer | (but yeah, /data - that's unencrypted while /home is encrypted) | 22:57 |
| fullermd | Just go ahead and spoil all my guesses, whydoncha... | 22:57 |
| aogail | :) | 22:57 |
| lifeless | jelmer: yes, and I grok that code | 22:58 |
| fullermd | I'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 |
| lifeless | jelmer: so one possible implementation is that there are a set of external objects available for packing against that are not going to be emitted | 22:58 |
| lifeless | mtaylor: note 't' vs 'T' | 22:59 |
| mtaylor | lifeless: yup | 22:59 |
| mtaylor | lifeless: but it was successful in the first command | 22:59 |
| lifeless | mtaylor: you're on windows? | 22:59 |
| mtaylor | lifeless: no, that's from a friend | 22:59 |
| lifeless | mtaylor: they are on windows | 22:59 |
| mtaylor | lifeless: yes | 22:59 |
| netdur | can bzr use ftp instead of sftp? | 22:59 |
| jelmer | netdur, yes | 23:00 |
| * mtaylor doesn't understand that choice, but whatever | 23:00 | |
| lifeless | mtaylor: file('foo', 'wt').close(); file('FOO', 'rt').read() | 23:00 |
| lifeless | mtaylor: will work on windows without error | 23:00 |
| lifeless | mtaylor: 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 quirks | 23:00 |
| mtaylor | lifeless: 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 |
| netdur | jelmer: thanks | 23:01 |
| aogail | Hmm. 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 |
| netdur | Peng_: would use sftp if my web host supports it | 23:01 |
| Peng_ | netdur: Yell at them about it. :) | 23:01 |
| lifeless | mtaylor: 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 |
| netdur | for $30 a year? they would just kick me out | 23:02 |
| Peng_ | Heh. | 23:02 |
| mtaylor | lifeless: AHA! that makes sense | 23:02 |
| fullermd | aogail: Well, it probably Should(tm) put that info there anyway. So now all you need is somebody to bug to implement it :) | 23:02 |
| lifeless | mtaylor: 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 |
| lifeless | sorry, missing: ....test...' | 23:03 |
| lifeless | nDuff: perhaps a mail to the list? I know there is interest in good vs integration | 23:04 |
| lifeless | nDuff: or just to me/Martin if you want to keep it low key | 23:04 |
| aogail | fullermd: Heheh, sounds good. Time to start hacking. ;) | 23:04 |
| aogail | Thanks. | 23:05 |
| jelmer | lifeless, 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 has | 23:07 |
| lifeless | jelmer: 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 revisions | 23:10 |
| jelmer | lifeless, true | 23:13 |
| netdur | when I branch via ftp, will bzr upload everything or just the diff? | 23:24 |
| netdur | hum, am messing things | 23:25 |
| netdur | say, I did branch, then added something new then branched again to the same place | 23:26 |
| === edcrypt_ is now known as edcrypt | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!