John Peacock wrote:
> How about this scenario?
>
> RepositoryA requires FilterA for .OoO files
> RepositoryB requires FilterB for .OoO files
> RepositoryC has no filter requirements at all
It might fail, but that's not subversion's problem. It's the
responsibility of the repository administrator and the users
to find a workable solution. Subversion should only provide
the hook.
You are sort of taking the stance that walking on a street is
dangerous and therefore people should be locked into their
houses all day.
Of course, walking on a street might be dangerous, but the
suggested workaround is not really acceptable.
Sorry for the exaggeration.
> The advantage with a wrapper is that each repository could have their
> own wrapper. Client-side hooks which are not tied in some way to the
> repository being accessed are going to be a serious problem (yes, you
> could have a more complex config format which encapsulates
> all of that
> information). It is *not* a simple problem to solve.
It isn't, but subversion developpers should not care.
> I get the feeling that most of the people arguing in favor of client
> filters are *nix people. Subversion runs on multiple platforms and
> there are multiple Subversion clients that are available (like
> TortoiseSVN) where this kind of "exec a filter" model just
> doesn't map well.
Well, although I'd consider myself a 'Unix person' my svn
problems usually show in an Windows environment.
Under *nix I could put everything I like into a Makefile and
be done.
Under Windows I am forced to use tools that are either not as
flexible or if flexible enough its a pain to exercise that
flexibility on a larger scale (No need to tell me there is 'make'
for Windows. _I_ know.)
So while I could be a bit more generous on what I consider
'source' on *nix I am fairly restricted on waht to use on the
Windows side.
Andre'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 9 08:24:00 2005