| Time | Nick | Message |
|---|
| 00:13 | | zwol left |
| 00:18 | | _4get left |
| 03:13 | | _4get joined |
| 03:27 | | zwol joined |
| 04:19 | | MichaelRaskin joined |
| 04:47 | | _4get left |
| 04:49 | | _4get joined |
| 05:25 | | zwol left |
| 05:45 | | MichaelRaskin left |
| 05:45 | | MichaelRaskin joined |
| 06:23 | | tommyd joined |
| 06:30 | | Guest976 joined |
| 06:31 | | _4get left |
| 08:28 | | MichaelRaskin left |
| 08:28 | | MichaelRaskin joined |
| 08:29 | thm | tommyd: births and marks could be exposed, (and marks are alreay via get_content_changed), but node ids probably should not, because they are strictly local |
| 08:56 | tommyd | thm: I played around with it yesterday and splitted get_manifest_of in get_current_manifest which has the same output format like the current manifest and works only in a workspace |
| 08:57 | tommyd | ...and a get_manifest function which needs an existing db revision and which has the "extended" format with all the marks and ids |
| 08:57 | tommyd | I did this because get_roster tends to crash when used in workspace mode f.e. if you have new, uncomitted files |
| 08:58 | tommyd | but another option could be of course to fix get_roster so it does not crash and use the same format for both functions |
| 08:59 | tommyd | the nice thing about that is that we then have a consistent API, i.e. get_current_{manifest,revision} and get_{manifest,revision} |
| 08:59 | thm | yep. |
| 08:59 | tommyd | I agree that node ids should not be part of the output |
| 08:59 | thm | and I'm undecided whether sizes should be part of the manifest |
| 09:00 | thm | it would be really nice information to have |
| 09:00 | tommyd | well, sizes should be part of the roster |
| 09:00 | thm | not necessarily |
| 09:00 | tommyd | and since a manifest is basically a "masked" roster nowadays... |
| 09:00 | tommyd | where would you put them? |
| 09:01 | thm | sizes could be stored in a separate table |
| 09:01 | tommyd | but I'd still love to get them with all the other information, i.e. marks |
| 09:02 | tommyd | it hurts performance if you need to iterate over a list of files just to get a single piece of information |
| 09:03 | tommyd | we could still then have some get_file_size FILE_ID function to _just_ get the file size of a particular file |
| 09:03 | thm | and how would you implement that? |
| 09:04 | tommyd | I haven't looked at the regnerate_rosters code yet, but I hope one would get the hands on the file blob there and would do a strlen() there |
| 09:04 | tommyd | this could be optimized of course by only touching those files which actually changed their content |
| 09:05 | thm | no, I mean for fetching the size of a single file, you have to create its blob then |
| 09:05 | tommyd | naturally the size of a file item could belong to a roster entry, just as its name and attributes |
| 09:06 | thm | no, that's wrong, because the size is directly coupled to the content hash |
| 09:06 | tommyd | right, I'd have to create the blob |
| 09:06 | thm | whereas name and attributes can change |
| 09:07 | tommyd | sorry, telephone, brb |
| 09:07 | thm | but of course presentation and implementation are different things. I agree that we want to see files sizes as part of the manifest. |
| 09:13 | tommyd | its correct, the size is coupled to the content hash - so you'd propose a new fileid - size relation table? |
| 09:13 | tommyd | to store these data normalized? |
| 09:13 | thm | that's what I thought about, yes. |
| 09:14 | tommyd | I mean I'd probably just repeat the same size for each file entry over and over again for each roster |
| 09:14 | tommyd | but isn't that what we do for birth marks as well? |
| 09:14 | thm | which wouldn't hurt, because we store roster deltas |
| 09:14 | tommyd | its a cache after all |
| 09:15 | thm | it's a question of use cases, and maybe manifest-with-file-sizes is more often used than a query filesize(content_id) |
| 09:16 | tommyd | I'd think so |
| 09:17 | thm | so, expanding the roster for this field is probably the way to go. |
| 09:18 | tommyd | but I have to admit that I haven't looked at all yet into the implementation - if its easier to have a separate table and to build a custom "manifest" format for automate usage based on the roster and the data from this table... |
| 09:19 | | Guest976 left |
| 09:20 | tommyd | but anyways, I'll have a closer look at this at first |
| 09:20 | tommyd | for my indefero interface I'm about halfway through and now stuck in their getTree() implementation |
| 09:21 | tommyd | to return all their wanted data currently I'd need to call get_manifest_of once and then for each node get_content_changed and certs (cached, of course) |
| 09:21 | tommyd | and the worst thing - to get the file size, I'd need to call get_file_of and calculate the file size myself |
| 09:22 | tommyd | this would get all too much time consuming and slow |
| 09:27 | thm | this is exactly what I'm doing in the trac backend |
| 09:27 | thm | and yes, it is slow ;) |
| 09:28 | tommyd | its always good when one technology pushes another |
| 09:28 | tommyd | if I wouldn't have started with indefero, I'd probably not keen to touch the roster code at all |
| 09:29 | thm | btw, what I don't like about the marks is that, if you are on a marked rev, you have to query the parents for their marks |
| 09:32 | tommyd | I have to admit that I don't quite understand some parts of that yet - one is in which cases a file can have two content marks |
| 09:33 | tommyd | I guess this happens in merge revisions, right? |
| 09:36 | | _4get joined |
| 09:36 | tommyd | i.e. starting from a merge revision there could be one mark iff the file did't change in a previous fork or two marks if it changed in either branch of the fork |
| 09:39 | thm | er, can we really have more than one content mark? |
| 09:40 | thm | wouldn't that lead to a content conflict which has to be solved somehow and leads to the merged revision being marked itself? |
| 09:44 | tommyd | thm: I wondered that myself as well - but the marker structure defines the content mark as set of revision_ids |
| 09:45 | tommyd | but while I ack'ed through the code I could only see single insertions in this set |
| 09:45 | tommyd | but the get_content_changed command is supposed to return more than one content_mark |
| 09:47 | thm | as far as I understand that, this can never happen |
| 09:47 | thm | maybe I need to grep through the database... |
| 09:47 | tommyd | while we're at it - under which circumstances can it happen again that there are no content marks for a file id? |
| 09:48 | tommyd | (shouldn't there normally also not at least the birth revision be displayed?) |
| 09:48 | thm | shouldn't happen either... |
| 09:49 | tommyd | I guess we surely have an understanding problem here |
| 09:49 | thm | did you see such a case? |
| 09:50 | tommyd | I remember I had a weird error case once in guitone where no content_mark was returned - let me check again |
| 09:50 | thm | mtn get_roster 276264b0b3f1e70fc1835a700e6e61bdbe4c3f2f shows identical birth and mark entries |
| 09:52 | tommyd | ok, no, I was wrong, I hadn't such a case - I actually have an invariant there that at least one revision is returned from get_content_changed |
| 09:53 | tommyd | I'll ask that on the list |
| 09:53 | thm | so, <1 shouldn't happen. >1 shouldn't happen either, but could once we have 'dormant' files. |
| 09:55 | thm | remember we were discussing problems of letting diediedie die? in that case we would have to deal with files with unresolved conflicts being resurrected, and the roster entries for these files could have more than one content mark |
| 09:55 | tommyd | the last dev which picked up the topic was Stephe and he didn't finished it back in the day |
| 09:56 | tommyd | I doubt we'll ever get rid of die-die-die |
| 09:56 | thm | actually I'm thinking about it once in while. |
| 09:56 | tommyd | but when did you commit your last code again...? ;) |
| 09:57 | thm | yeah, hit me with a stick. |
| 09:57 | tommyd | nah, at least you're still around :) |
| 09:57 | tommyd | and you still do packaging, user support and all - thats fine |
| 09:59 | thm | ;) |
| 10:34 | | riz left |
| 10:48 | | tommyd left |
| 10:49 | | tommyd joined |
| 11:41 | | MichaelRaskin left |
| 12:26 | | stefan left |
| 13:03 | | stefan joined |
| 15:05 | | tommyd left |
| 15:23 | | zwol joined |
| 15:59 | | tommyd joined |
| 16:14 | | _4get left |
| 16:18 | | _4get joined |
| 16:32 | CIA-9 | me@thomaskeller.biz net.venge.monotone * raa335ab466a3cfdd502eea287817466402d42b6c /monotone.texi: * monotone.texi (get_content_changed): describe under which circumstances no, one and multiple content marks are returned for get_content_changed |
| 16:32 | CIA-9 | tero.koskinen@iki.fi net.venge.monotone.tkoskine.purge * rbc9d17b3d81877fe226c376646c89ebc96540ca9 /cmd_ws_commit.cc: |
| 16:32 | CIA-9 | Add a new "clean" command. |
| 16:32 | CIA-9 | Also known as "purge". |
| 16:32 | CIA-9 | tero.koskinen@iki.fi net.venge.monotone.tkoskine.disapprove-multirev * r7312b0fad95671e6d3ecd4d13b56bec0bfa2827b /cmd_ws_commit.cc: Initial bits of multirevision disapprove. |
| 16:32 | CIA-9 | tero.koskinen@iki.fi net.venge.monotone.tkoskine.disapprove-multirev * rf2d63bb0611f666d19453d4a8f9ac1bafc1d5d44 /tests/ (14 files in 2 dirs): Add two tests for the multirevision disapprove. |
| 16:55 | | tommyd left |
| 17:16 | | tommyd joined |
| 17:27 | | riz joined |
| 17:30 | | tommyd left |
| 18:29 | | gizmo1 left |
| 18:55 | | tommyd joined |
| 19:07 | | tommyd left |
| 19:15 | | stefan left |
| 19:17 | | stefan joined |
| 19:31 | | tommyd joined |
| 19:33 | thm | tommyd: ah, I forgot the accidental clean merge |
| 19:34 | | MichaelRaskin joined |
| 19:36 | tommyd | I thought of it actually, but in the wrong way |
| 19:37 | tommyd | I edited a single file two times equally, but I forgot that other (unrelated) files needed to be edited as well which leads to different rev ids |
| 19:37 | tommyd | anyways, its now in the docs, so if we forget it again... ;) |
| 19:38 | thm | good. |
| 19:57 | | stefan left |
| 19:59 | | tommyd left |
| 20:09 | | gizmo1 joined |
| 20:09 | | gizmo1 is now known as Guest1033
|
| 20:10 | | Guest1033 is now known as gizmo1
|
| 20:21 | | gizmo1 left |
| 20:24 | | gizmo1 joined |
| 20:24 | | gizmo1 is now known as Guest1036
|
| 20:25 | | Guest1036 is now known as gizmo1
|
| 20:55 | | stefan joined |
| 21:12 | | tommyd joined |
| 21:22 | | zwol left |
| 21:31 | | zwol joined |
| 23:10 | | zwol left |
| 23:10 | | zwol joined |