Greetings, David Weintraub!
> On Tue, Mar 2, 2010 at 11:39 PM, Andrey Repin <anrdaemon_at_freemail.ru> wrote:
>> Sorry, my head is a bit crippled for now, and your post contains too much
>> cross-references to be understandable in my current state.
>> Could you please put it in simple terms, how you see your potential system
>> works?
> We have both development teams in India and in New York. When the
> Indian development team makes changes, the New York QA team needs to
> be notified, so they know what to test. When the New York development
> team checks something in, the Indian QA team needs to be notified.
> This will currently be for a single project, so I have to specify
> those files in that project that need to be watched.
> I decided to make this hook script a bit more general than for this
> specific circumstance. What if there are separate teams for each
> branch that need to be notified? What if other teams want their files
> to be watched?
Having generalized hook script is always a nice option, if you ask me.
Given sane configuration scheme, you never know, how unexpectedly nice setups
your users would be able to build.
>> If having a custom (and client-customizable) configuration is all you ever
>> want, there's a hint: hook script can access repository as easy as any other
>> local file. Just do "svn cat" on required file and parse it's content as
>> normal.
>>
>> However, be very wary of access rights on the mentioned configuration file.
> I am using "svnlook cat" which is a bit faster
Right, and thanks for a note.
> since I don't have to go through the Subversion server. I will be setting
> the rights on this configuration file, so only the managers can modify it.
> Plus, I'll get an email whenever the configuration file itself gets modified.
> Originally, I was thinking about using properties to set the watch. If
> I want a particular directory tree watched, I could put a sol:watch
> property on that directory, and anytime a file in that directory tree
> gets modified, I'll email the users.
I didn't though about properties, but I clearly see a perfomance issue you've
mentioned below. You have to enumerate whole tree back up to the repository
root in attempt to locate the properties, and you can't just stop in the
middle after first such property found.
> However, how do you find all of these properties? If I check in a file
> svn://host/project/dir/dir2/dir3/file, I'd have to check all the
> parent directories for the property (that's five different directories
> to check, plus the file itself). And, I'd have to do that for each
> file changed. Plus, how do developers find all of their watches?
> Therefore, I decided it would be better to have a single configuration
> file for the watches.
> Another possibility is to have a directory where users can put their
> own watch definitions. I have an access control script that can easily
> be setup so that barry.cfg can only be changed by barry and david.cfg
> can only be changed by david. But, that means getting a list of these
> watch files (svnlook tree), and then checking opening up each one to
> construct my watch list. That might take too long.
You're missing one option - put a post-commit hook on this directory, which
would compile single configuration file from all user files.
I.e.
<svnroot>\watch\watchlist (global options)
<svnroot>\watch\watchlist.d\<someuser>.list
<svnroot>\watch\watchlist.d\<someotheruser>.list
Every time your post-commit (or pre-commit, if you decide) hook spot a write
operation to the \watch\watchlist.d, it run compilation process, and notify
repository administrators of the results.
You can store compiled config out of repository, or inside it - as you decide.
I'd go with off-site approach, as it could be reconstructed at any time,
whenever the repository moves.
--
WBR,
Andrey Repin (anrdaemon_at_freemail.ru) 04.03.2010, <17:27>
Sorry for my terrible english...
Received on 2010-03-04 15:45:41 CET