rest and write the rest in full_message - just like we do it for log and
everything else. This is ugly, really ugly, because it assumes something
on the format of a commit message, which might not be true at all for
some project, but this is something Loic has to decide (see also issue 491
and issue 535)
part of another branch whose certs haven't been pushed into the server
yet, so we need to skip these revisions while going back in time
for the changelog. The initial revision however must carry a branch
cert, otherwise we have nothing to "follow".
to the same signal also for the initial setup, since the memberships
haven't been added at the time the create signal is thrown
* my array references goo was slightly stupid (the usage of foreach
is of course hazardous in cases like this)
* always insert a trailing new line in write-permissions and skip
read-in newlines from being processed
indentifiers in IDF - the SCM function isValidRevision has been replaced
by a validateRevision() method which returns one of three states,
valid, invalid or ambiguous.
The source view can then act accordingly and display disambiguate view
for the latter, so the user can select for which revision he actually
wants to execute the requested action. Also, invalid revisions now lead
to another separate view, telling the user that it is invalid / does
not exist and pointing him optionally to the help page where he can read
further how to access his repository to push the first changes into.
(partially resolves issue 525)
won't return variable references properly, so revert that change
again
- since we're requiring 0.99 now, we also have to use au generate_key
instead of au genkey
when new revisions arrive. this still needs some more tests, but
its a start.
- refactor out the monotonerc template from SyncMonotone.php and
place it in a separate template file (access control hooks are
still missing from there)
we can skip the explicit configuration of its host and admin
password, as we can directly read that from the configuration file
itself
- expand the SyncMonotone plugin a bit to where this actually becomes
useful, i.e. create an accompanying key for each created database
and also add some initial database-specific configuration
- update the config docs in idf.php-dist to reflect the changes and
add more details about the inner workings of the SyncMonotone plugin
project creation and adds the new server to the running usher instance.
If everything goes well, the usher instance is told to reload its
configuration, so the new server / database is picked up and started
automatically.
* src/IDF/Key.php: new column "type" which is either "ssh" or "mtn";
utility functions to query the mtn key name and id as well as
all available key types for the current IDF installation
* src/IDF/Migrations/16KeyType.php: needed migration script
* src/IDF/Plugin/SyncGit/Cron.php: ensure only SSH keys are handled
* adapt forms and templates accordingly
"usherConfigured" to denote whether we render links to the usher
control functions in the forge administration
* src/IDF/Scm/Monotone.php: moved IDF_Scm_Monotone_Stdio into
separate file src/IDF/Scm/Monotone/Stdio.php
* src/IDF/Scm/Usher.php: new class to query and modify the state
of a running usher instance
* src/IDF/Views/Admin.php: add actions to query the list of
configured servers, edit their status, view their open connections
and control the state of the usher as a whole
* src/IDF/conf/idf.php-dist: optional usher configuration added;
mail address of monotone-users added; spelling changes
* src/IDF/conf/urls.php: added needed URLs for usher actions
* src/IDF/templates/idf/gadmin/base.html: usher links
return a list with selectors as keys, otherwise the main menu won't
link the active revision, but instead use the main branch
* changelog.html, tree.html: shorten the branch / tag output a bit
(still ugly to have a fixed output like this, though), link tags
by their selector, no longer by their revision ID. We loose some
flexibility here, since tags could actually mark different
revisions, which are now ignored
add two scenarios, one with a single, global database and one with
multiple project databases and usher as proxy; add an option for additional
command line options for the mtn process; remove the protocol type
configuration option - we're handling this implicit with the new
mtn_remote_url configuration
* Monotone.php: add the IDF user for ssh:// URIs; add support for remote_stdio
and rework the command line stitching
* IDF_Project: optionally give getSourceAccessUrl() a commit argument, so a particular VCS module can determine a subset of revisions to pull for the specific revision which is browsed
* IDF_Scm_*: add the argument null'd for all VCS; implement a branch lookup for monotone
* tree.html: display the correct branch to clone under each revision tree
* Monotone.php (IDF_Scm_Monotone_Stdio): add support for multiple, equally named options
* Source.php, commit.html: split-off the global commit template (which had some separate code already for SVN) and adapt the left blocks for mtn to shorten branch and tag names just like we do everywhere else