- getPathInfo(), disambiguateRevision() and validateRevision() are done
- we no longer need to check / skip a format_version stanza for the extended
manifest (there is no such stanza outputted)
Main test infrastructure is there, still lots of functionality left
for testing. Fixed a possible bug in the SCM interface already:
Pluf_HTTP_Response_NotFound needs a request instance as ctor argument,
which we don't have at this point, therefor we just throw an exception.
- create an interface that describes the basic methods
- let the real stdio class implement this interface
- inject the stdio instance into IDF_Scm_Monotone and do not
create it in the constructor
- ensure in IDF_Scm_Monotone_ZipRender that we get the proper
constructor arguments
On a slighly unrelated note, make _getAuthOptions() in the stdio
implementation private.
Added a template for getting a controlled log; in parseLog, changed the regular
expression to match the pattern used in the template (fixes issues 507 and 508).
The diff parser code was rewritten for clarity and speed and now handles
a couple of ugly cornercases, like SVN's property change output and single
change chunks, much better. Since the path parsing was unified as well,
the SCM interface gained a new method `getPathStripLevel()` which determines
how many path components need to be shoven off a file name for the SCM
to form a valid path in the workspace (similar to patch(1)'s --strip option).
Fixes issue 627. Automated tests follow.
This works similar to git branch --contains REV; additionally give the
revision id and not some possibly symbolic name to the inBranches()
call when we determine the branches a commit is in.
a revision from which we want to start our log from, but simply ignore
that and go over to the next revision. Note that this is also a bit
fragile and should probably be converted to plain mtn au log usage.
configuration tree as template for a new project and copy / symlink that on
project creation. To make this process a little more configurable, two new
configuration options, 'mtn_confdir' and 'mtn_confdir_extra', have been
added which allow the forge admin to adapt the directory structure and its
default hooks to his likings for all new projects. (More on that in
doc/syncmonotone.mdtext).
The 'mtn_remote_auth' configuration option was removed, because setting this
to false would have not worked for setups which did not allow write access
to remote automate commands for anonymous users and opening this would have
meant a huge security hole. Instead, for every project which is created a
corresponding client key is created as well which is used as authentication
in the IDF source frontend.
Finally the monolithic monotonerc file has been split up into individual,
easily configurable lua files which are linked / copied underknees hooks.d/
and which do not conflict with each other (for example by overwriting certain
main notification hooks).
* Scm.php: new SCM method "getChanges" which returns all available
change information grouped by type
* Monotone.php: implement getChanges via get_revision
* <other scms>: rename "changes" member for getCommit to "diff" which
matches better
* Source.php: query the commit's changes and set them in the template
* commit.html: render the changes, type-by-type. Link to the tree or
the individual diff if applicable
* styles.css: some initial style sheet work
the branch certificates in question to the horizont, otherwise we end up going
up the whole history for some feature branch as soon as we hit the base branch
of a project.
mercurial and monotone, but slightly harder till impossible to
do properly for git and svn. Please review and eventually adapt
the code to make it work better (partially fixes issue 450)
Instead of returning a command which gets executed and which should
pass through / stream its output data to the client, we're just
returning an instance of Pluf_HTTP_Response. This is needed, because
some SCMs, most noticable monotone, have no locally executable command
to provide a snapshot archive (and probably never will for our kind
of setup).
We therefor added a little BSD-licensed class "ZipArchive" which allows
the creation of pkzip-compatible archives on the fly by letting it eat
the file contents directly feed from the (remote) stdio instance.
Download performance is ok and lies between 15K/s and 110K/s, but at
least we do no longer block the browser while we pre-generate the zip
file server-side.
Thanks to Patrick Georgi for all his work!
- getTree(), getPathInfo(): use the new extended manifest format
and save the calls to query file sizes from contents as well
as the calls to determine the revision in which a file changed
at last
