On 12.06.2005, at 05:38, Steve Wardell wrote:
> Ryan Schmidt wrote:
>
>> On 08.06.2005, at 20:00, Steve Wardell wrote:
>>
>>> I'm looking at replacing an existing Sharepoint system
>>> with one that uses Subversion as a back-end. I'd like
>>> users to be able to subscribe to specific files. Is
>>> anyone aware of any tools that integrate with
>>> subversion as a backend to allow specific document
>>> subscriptions?
>>
>> What does it mean to you to subscribe to a file?
>
> Subscribing means that you're notified when that file
> or directory is updated. This could be immediate or
> nightly thing. This is for documents and design
> documents and not for source code that we wish to use
> such a subscription.
I'm not aware of a pre-made system that meets those needs, but it's
fairly easy to make yourself. In my company we have written a
post-commit hook where developers receive diffs of commits to specific
directories -- the directories of the projects they're working on at
the time. Subscribing and unsubscribing is currently handled manually
through the system administrator, but it will be moved to a web front
end with a MySQL database in the future.
> You can catch the changes in the post commit, but it
> has no integration with any sort of filtering on what
> changes to notify which users on.
You do this by svnlooking at the revision that was just committed --
"svnlook changed $REPO -r $REV" will tell you what files were affected
by the commit. You can match these places against your list of
subscriptions and send out either the diffs or if you don't care about
that then just the names of the files that were changed about which
this person wanted to be informed.
> Additionally, it would be nice to have it in nightly
> cron job vs instanteously.
You could do this by saving the youngest revision in a text file:
"svnlook youngest $REPO > /path/to/youngest.txt". In the cron task, you
would again get the youngest revision, and for each revision between
the previously checked one and this one, do what was described above,
probably summing up the changes for each user so just a single email
with all changes could be sent, rather than one email for each change.
Then at the end you write the youngest revision to the file again.
"svnlook changed" appears to accept only a single revision number, so
you may need to do a loop and call svnlook several times, one for each
revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 12 12:33:33 2005