Michael,
Sorry if you get this twice. I forgot to send it to the mailing list
the first time.
On May 25, 2005, at 2:25 PM, Michael L Brown wrote:
> --
> Mike Brown (Michael.L.Brown@Philips.com)
> Lotus Bloats: Michael L Brown/MSN/MS/PHILIPS
> Philips/ADAC, Madison, WI
> Desk: 608-288-6969 Fax: 608-298-2101
> PMS direct: 164-6969
> You design it, I'll build it!
>
> William Nagel <bill.nagel@gmail.com> wrote on 05/24/2005 03:42:18 PM:
>
>
>
>> Hi all,
>>
>> I'd just like to announce the official release of my new book:
>>
>> Subversion Version Control: Using the Subversion Version Control
>> System in Development Projects
>>
>>
>> It's a fun-filled romp that follows the adventures of a miscreant
>> youth as he matures in the deep south...
>>
>> Or maybe it's a new Subversion book that looks at how you can get
>> more out of integrating Subversion into your development process,
>> from the perspectives of the version control newbie, the client user
>> (e.g. the software developer), the repository administrator, and the
>> project manager.
>>
>> I guess you'll just have to buy to book to find out exactly
>> which... :-)
>>
>>
>
> I agree with everything mentioned on the back cover, except:
>
> "This book introduces you to Subversion, a free, open-source version
> control system, which is both more powerful and much less complex than
> its predecessor CVS."
>
> More powerful, yes. Less complex, nope. As pointed out in previous
> postings, our situation with binary files and how not to have them get
> affected with svn:keywords property substitution is becoming a real
> complex issue for us. With CVS, a single global file contained a list
> of files that would automatically get marked with the -kb option,
> which kept them from having keywords substituted. Said feature does
> not exist with SVN.
>
Hmmm... That is a tricky problem. Although I stand by my assertion
that overall SVN is much less complex than CVS (mainly due to a much
cleaner interface), it is true that there are some specific things
that are more complex, and this is certainly one of them.
>
> Now I have to write a hook script, or more, to do that work for us.
> The note mentions that you have hook script examples. Are your
> examples
> to the point that I can use them to figure out what I need to do,
> i.e.,
> check that it is a text file of the type that I would check for and
> then set the property? Plus, make sure that the user didn't set the
> property by mistake (which we didn't do with CVS)?
>
The book does have several hook script examples of varying complexity
(including a couple that are fairly involved). Unfortunately, I
don't have an example in the book that specifically addresses your
issue or one like it. I do talk about the things you can/can't do in
hook scripts though, as well as the ways the various SVN tools can be
used inside of a hook script.
For the most part, I encourage using hook scripts to validate policy
and reject commits that don't follow the appropriate policy with an
error message that explains what needs to be done. Although you can
use a post-commit hook to perform a second commit to make the
property change, I think that adds an extra layer of complexity and a
failure point (the client needs to update to get the version of the
file that has the property set).
>
> Something just came to mind that I didn't think of before... would it
> be easier to look for the fact that it is a binary file and make sure
> that the proprty isn't set and just set it for all other files? I
> have a list of all the binary types that we have, since it is in the
> CVS configuration file. Like I said, and another poster agreed with,
> using the user's .subversion/config file for doing this is just not
> viable.
>
If it were me, I'd supply the users with a .subversion/config file
that they should use, and then use a hook script to make certain that
they do indeed use it (by checking that the properties have been set
correctly).
>
> I want to use the KISS principle on the whole process. The more
> complex it is, the more prone it is to error.
>
Agreed, but I personally think modifying the repository (even in a
post-commit hook script) is more complex and error prone than a hook
script that rejects invalid commits.
Anyway, I wish I could tell you that my book would help solve all of
your problems with this issue. Unfortunately, I'm not sure it has a
lot in it that will help you out.
-Bill
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 25 23:17:05 2005