John Peacock <jpeacock@rowman.com> writes:
> And I cannot tell why placing the burden of determining primacy on the
> server hook solves the problem in any way either. Some process still
> has to determine which competing log-template gets used; by punting
> completely, you place *all* of the burden on the site admin to take
> this [possibly marginal in real life] use-case into consideration when
> writing the hook script.
>
> Here's a couple of ideas for dealing with conflicts (straight from my
> brain to your eyes, no thought to complexity of implementation):
>
> 1) Highest One Wins - the template in force for the shortest path that
> contains all committed file paths.
>
> 2) To Each His Own - If those 20 files are covered by 3 log-templates
> (for example), then the client splits the commit into 3 seperate
> commits, each with it's own custom template. We should be able to
> assume that if a site has that many templates scattered about their
> tree, then that should be taken as a significant factor and we should
> respect the effort and not impose a single template.
>
> Of course, in both cases a --no-log-template switch to the client
> should shut off all special processing and lead to the existing "dumb"
> template. Any site wishing to require specific formatting has to use
> the pre-commit hook to validate the text anyways.
John, your scenario assumes that the server admin has *already*
implemented some sort of per-directory template association. Let's
remember that they don't have to do that at all. They can just ignore
all those paths, or do something else with them.
If the admin has implemented per-directory associations, and needs to
come up with a resolution policy, then consider the possibilities:
1. It's trivial. In which case, we have not burdened the admin
overmuch by asking them to do it.
2. It's complex. In which case, since it's already going to be
difficult for the site admin to implement, with all her
site-specific knowledge, then there's no *way* we could ever
have gotten it right with some pre-determined algorithm!
In short, while there are some arguments against Fitz's hook proposal,
I don't think this is a convincing one. The problems raised here feel
like either non-problems, or problems that are so complex that they
are precisely why Fitz came up with the flexibility of the generic
hook in the first place.
Note that we can easily ship a contrib/ script that implements your
highest-wins scenario. Meanwhile, splitting 1 commit into N commits
sounds very unfriendly to me; if a site wants such drastic behavior,
it can enforce it in pre-commit. SVN shouldn't be doing it as a
matter of course.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 19 23:20:32 2005