Zeus Gómez Marmolejo wrote:
> Quoting Tom Mornini <email@example.com>:
>> Wrap svn commit in a simple script that does:
>> 1) crawl through current directory and children
>> 2) pretty print .c files
>> 3) svn commit
> OK, this option is much like what I want. But, I can wrap the server
> svnserve? Or it's done in the clients? If it's done in the clients we have
> the same problem as before. If I can wrap the server command 'svnserve' to
> check the .c files first and then do the real 'svn commit' is fine for me.
> Another thing that I'm thinking about, related to what Erik suggested,
> is to
> checkout the repository at midnight in the server as a cron task, run the
> pretty-printer software and if the result is different from what it's in
> server, commit a new revision each day.
Here's another alternative: Create a post-commit hook that updates a
working copy on the subversion server, pretty prints your source files,
and commits it. This will obviously result in two commits (developer and
post-commit hook) and the committer will need to update his working
copy. If it solves your problem it might be worth the inconveniences.
>> Why, oh, why...would you argue with people who wrote the tool and
>> they're wrong about the tool itself.
> I'm completely agree with developers, but I don't understand how you don't
> accept that the software might do this new thing. What I'm proposing is a
> different functionality that the tool doesn't have: the possibility of
> changing the transaction in pre-commit time. I think it's worth mentioning
> it. May be this situation will happen again in the near future but not with
Although I would do this as part om my development or build environment
as other people suggested, this is an example of the flexibility of
subversion (and foresight of its developers). You just gotta love it :-)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Aug 19 18:02:59 2004