Log of /contributions/modules/versioncontrol/hook_versioncontrol.php
Parent Directory
| 
Revision Log
| 
Revision Graph
Revision
1.14 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri Oct 16 14:15:26 2009 UTC
(5 weeks, 6 days ago)
by
sdboyer
Branch:
MAIN
CVS Tags:
HEAD
Changes since
1.13: +12 -16 lines
Diff to
previous 1.13
Merging in work from git by marvil07 for his GSOC project to OO-ify vcsapi. From this commit forward, HEAD is OO.
Revision
1.13 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Jun 21 15:33:07 2009 UTC
(5 months ago)
by
jpetso
Branch:
MAIN
Branch point for:
DRUPAL-6--1
Changes since
1.12: +12 -2 lines
Diff to
previous 1.12
Make the "data" column usable by other modules, and migrate more data to it.
This enables us to get rid of the {commit_restrictions} and
{versioncontrol_repository_metadata} tables, whose data is now
stored in $repository['data'] instead.
Requires an update.php run. This commit modifies update 6102 which
I introduced in my previous commit two days ago; if you have already
executed that update then please delete the "data" column from your
{versioncontrol_repositories} table and run it again.
Revision
1.12 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Wed Apr 8 12:58:31 2009 UTC
(7 months, 2 weeks ago)
by
jpetso
Branch:
MAIN
CVS Tags:
DRUPAL-6--1-0-RC1,
DRUPAL-6--1-0-RC2
Changes since
1.11: +67 -1 lines
Diff to
previous 1.11
#426376 by CorniI and jpetso:
New API function versioncontrol_update_operation_labels(),
along with a new hook for reacting to operation label changes.
Good thing that there's finally an API for this - without this code,
backends like Git were required to place queries into Version Control API's
private database tables, and secretly modify stuff that had been publicly
exposed to modules by hook_versioncontrol_operation().
Now there's a sufficiently clean way to do the same thing.
Revision
1.11 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri Apr 3 22:06:57 2009 UTC
(7 months, 3 weeks ago)
by
jpetso
Branch:
MAIN
Changes since
1.10: +8 -2 lines
Diff to
previous 1.10
#328035 by Cornil, plus a lot of changes from me:
Make VCS username suggestions and determing username validity pluggable.
Also, fix a bug in the user versioncontrol page that made the passed
repository work incorrectly.
This should make it possible to handle Git & Co. usernames properly.
Revision
1.9 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Jan 25 15:43:23 2009 UTC
(10 months ago)
by
jpetso
Branch:
MAIN
Changes since
1.8: +2 -2 lines
Diff to
previous 1.8
* Port the 5.x workflow_ng integration to 6.x Rules integration.
* Get a drupal_mail()-like $send option into Commit Log's
notification mail functions, and remove 'send' from the function names.
* Bonus feature: new "send notification mail" action for Rules,
and a few more operation properties exposed as event arguments.
Per-user commit subscriptions are now *really* not far away anymore.
Everything involving mails is still untested though,
but despite that I also fixed one bug in the process :)
Revision
1.7.2.1 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Oct 26 20:15:06 2008 UTC
(13 months ago)
by
jpetso
Branch:
DRUPAL-5--2
CVS Tags:
DRUPAL-5--2-0-ALPHA1
Changes since
1.7: +2 -2 lines
Diff to
previous 1.7
Remove versioncontrol_get_all_item_{branches,tags}() in favor of a new
versioncontrol_get_parallel_items() function that does both, and does it
in a way that fits with the other 'selected_label' stuff that was
recently introduced.
That kinda discards sdboyer's commit tackling the same issue, which I felt
was not solving the guts of that todo item as the label handling was not
adapted, and the versioncontrol_backend_implements() calls introduced by
the last commits are indeed meant to be called by the API user and not by
the API module itself (so that was actually ok before.)
Sorry Sam, I hope you don't take offense about that...
Also, introduce versioncontrol_is_deleted_item() (small helper function)
and purge the get_item_history() example out of the FakeVCS backend as
there's (currently) no way to support or implement this directly by
the backends.
Revision
1.7 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sat Apr 19 13:11:05 2008 UTC
(19 months, 1 week ago)
by
jpetso
Branch:
MAIN
Branch point for:
DRUPAL-5--2
Changes since
1.6: +2 -2 lines
Diff to
previous 1.6
* Extend label restrictions to branch/tag-emulating commits,
and clean up a bit more... the code's a lot nicer to read than yesterday.
* Update copyright headers to 2008.
Revision
1.6 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sat Apr 19 11:16:15 2008 UTC
(19 months, 1 week ago)
by
jpetso
Branch:
MAIN
Changes since
1.5: +5 -5 lines
Diff to
previous 1.5
* Port Commit Restrictions to the new API, and clean it up some more.
* New API functions: versioncontrol_is_{file,directory}_item().
* Plus some other smallish API and documentation fixes/modifications.
Revision
1.5 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Thu Mar 13 21:44:30 2008 UTC
(20 months, 2 weeks ago)
by
jpetso
Branch:
MAIN
Changes since
1.4: +143 -324 lines
Diff to
previous 1.4
Next step in porting to the new database schema:
Implement loading operation items, and unify the write access and
insertion functions (with the new implementation of inserting items
not done yet). Random porting also in other places.
Have I mentioned that the docs are far more work than the code?
Anyways, it's worth the hassle.
Revision
1.4 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue Feb 12 21:06:04 2008 UTC
(21 months, 2 weeks ago)
by
jpetso
Branch:
MAIN
CVS Tags:
DRUPAL-5--1-1,
DRUPAL-5--1-2
Branch point for:
DRUPAL-5
Changes since
1.3: +1 -4 lines
Diff to
previous 1.3
Subversion pushes our assumptions about how commit actions can look like
to the next level. Among those assumptions is that modified files
don't change their path and branch: wrong in Subversion, because
moving a parent directory will leave items inside that directory
completely untouched. Only when it's modified afterwards, a commit action
happens for this item, and then it suddenly has a new path.
Branches also don't need to stay the same, as a simple move between
Subversion directories can yield different branches for source and
target item.
This commit removes these assumptions from the API documentation.
Revision
1.3 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Mon Jan 21 10:52:40 2008 UTC
(22 months ago)
by
jpetso
Branch:
MAIN
CVS Tags:
DRUPAL-5--1-0
Changes since
1.2: +23 -8 lines
Diff to
previous 1.2
Holy moly! Here comes the big fat operation factoring commit.
Commits, branch operations and tag operations now derive from one
base object (an "operation") which has most of its properties stored
in the new {versioncontrol_operation} table.
+ More consolidation, less duplicate code,
and less duplication in the table structure.
+ One operation id to rule them all.
+ Potential for introducing a combined versioncontrol_get_operations()
function that can retrieve all three kinds of operations. Later, though.
+ A few bug fixes.
+ Comes with an upgrade path. Scary, though, I hope I won't ever
have to do an update function like this again.
- Even more abstraction, which makes the database scheme even harder
to grasp.
- One more join in important SQL queries.
Revision
1.2 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri Nov 9 20:23:25 2007 UTC
(2 years ago)
by
jpetso
Branch:
MAIN
CVS Tags:
DRUPAL-5--1-0-RC4
Changes since
1.1: +4 -1 lines
Diff to
previous 1.1
This isn't the first time that a query fragment like 'WHERE column = ()'
causes problems. Try to avoid those cases by explicitely checking
the constraints on emptyness and returning FALSE for constraints
that are set but empty.
Also, prepend hook_versioncontrol_filter_account() instances with a check
if there are accounts in the list at all. Fixes the bug that was reported
by "world" on #drupal-dev.
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
select a symbolic revision name using the selection box, or choose
'Use Text Field' and enter a numeric revision.
