[Mono-devel-list] Re: [Mono-patches] r36124 - trunk/mono/mono/mini

[Ben Maurer]

> Note that archiving mono-patches is also a poor man's workaround for
> cvs' (and, alas, svn's) lack of distributed support, since
> we acan access it while disconnected.
svk could help with this, no?

>> This last point obviates the need for a Changelog at all;  'svn log'
>> on  the root of a project *is* the Changelog.  It can be dynamically
>> generated at any time.
>
> Yes, some people do that with cvs, too. We require the changelogs
> because that way they are available offline and in the tarballs we
> distribute. Maybe you can make svn log work offline like the modern
> distributed systems: in that case we might reconsider our changelog
> policy.

We could make a script to generate changelogs in our tarballs.


> Once svn implements per-file comment logs and offline svn log it will
> be better suited for our development policies and when it will have a

I think we could hack this in with the current system. Ben, can you tell
me if this is realistic:

Each tree has `unversioned properties' that we can set on it. Basically,
what this means is that we can attach an arbitrary datum to each tree
with a specific name. svn uses this to store the log files that are
written. So what we can do is to define our own property, `changelog'.
It would be an xml file, that looks something like:

<change-set rev="36564" author="benm" time="some time format">
   <file-change file="source/trunk/mono/mono/mini/mini.c">
       <function-change name="mono_do_foo">
            Make sure the foo does bar, to fix bug #65546
       </function-change>
   </file-change>

   (and so on)
</change-set>

We'd need to find some way to make sure this file gets cached on the
local disk (if the user wants that -- so that they can do offline
browsing). We'd also need to write a tool to query this information. It
is probably possible to make svn generate a svn:log message for each
commit given this (just generate a regular changelog style message). SO
the svn log will still be messy, but we wont use that command.

Also, this would not work for old changes (unless maybe we parse our
changelogs with a script...but even if svn did add support for per file
logs, we would have the same problem.

One question is how to generate this xml file, as it is verbose. We'd
probably want a script to do it. Also, we'd probably need more fields,
say for a summery of changes in one changeset.

We would also need to enforce the use of this changelog format, prehaps
by pre-commit hooks.

Ben, does this sound realistic?

> usable svn annotate it will also better support our development
> practices:-) Thanks.

I talked with Ben yesterday about the problem here. Basically here is what
happens (this is with a 1.1 client and server). The client asks for
r{1..99} of a file, in that order. However, the server has deltas that go
backwards from 99 to 1. So what it does is to generate teh full text
version of each file, starting with 1, by using the reverse deltas. Then
it does a difference, going forward, and sends these differences and r1 to
the client. The client reconstructs the revisions in order, adn then
creates an annotation. So yes, this is fairly slow (in fact, svn blaming
mini.c takes up 40 secodns of cpu time on the server). Ben said that they
have some ideas for this. I am not sure when such a feature would be
added.

-- Ben