uprooter wrote:
> Hari.
> If I get you right, I need to implement some build script(driver) that the
> developers should run whenever they commit.
> How can I force such a thing without reconfiguring the clients?
> does that means that I must edit every build script, whether it's a visual
> studio project or ant script or Makefile. and put that build driver in it ?
> And what happens if someone creates a new project ? would it be possible that
> something will force him to use that build driver ?
>
>
> On Wednesday, 2 בApril 2008 00:18:43 you wrote:
>> On Tue, Apr 1, 2008 at 1:55 PM, uprooter begee <uprooter_at_gmail.com> wrote:
>>> Hi hari.
>>> Thanks for the reply.
>>> Client side is just not a solution.
>>> one missconfigured client can make a versioning issue that will
>>> eventually cost more then commercial VC software. :)
>>> There must be a way to really hook the commit and not pre/post commit
>>> hooks.
>>> Or, alternatively , to modify the raw data without committing in a
>>> safe manner.
>>> What about webdav? will svn let me overwrite files without commit this
>>> way ?
>>> And the svnput.c Can I tweak it to let it just do the putting part
>>> without the commit?
>> As John said, don't modify it in the pre/post commit. I do not know if you
>> can use svnput.c or a webdav interface to update the repository without
>> doing a 'commit'. I highly doubt that svn would allow you to do that. For
>> me that will be a risk and not a feature.
>>
>> One thing that you may be confusing is the whole "client-side" part. I am
>> not sure what you mean when you say "one *misconfigured client* can...".
>> The solution discussed in the FAQ link is not a subversion client
>> configuration. This is a script that you write and place it into
>> subversion. But the script acts not on the files in the server, but on the
>> files checked out on the client (exactly like a build script).
>>
>> For example, you can have a driver build script, say build.xml. This script
>> calls appropriate lower level build file (make, ant, whatever is the
>> associated file for C# etc) according to who is building it or which
>> project it is building etc. Before it calls the lower level build file,
>> this build.xml will use the 'svnversion' command to create a version file (
>> version.h, or version.java -- I don't know.. something that can be used by
>> all projects).
>>
>> You should then check-in build.xml into your repository and everyone in
>> your team will use this file. Everyone gets the same file from the
>> repository and will execute the same code; and there is no question of
>> 'misconfiguration'.
>>
>> hope it helps,
>>
>> regards
>> -Hari
>>
>>> On
>>> Tue, Apr 1, 2008 at 10:40 PM, Hari Kodungallur <hkodungallur_at_gmail.com>
>>>
>>> wrote:
>>>> On Tue, Apr 1, 2008 at 11:29 AM, uprooter <uprooter_at_gmail.com> wrote:
>>>>> Hi john and thank you for your quick reply.
>>>>>
>>>>>>> Is there a way to modify that file from pre-commit without
>>> incrementing
>>>
>>>>>>> the revision?
>>>>>> No, you must not alter file contents in the pre-commit hook
>>>>>> (because then it would not be the same data that the client just
>>>>>> sent).
>>>>> Well, the client would not commit the "version.h" file. I can be
>>>>> sure
>>> about
>>>
>>>>> that. I can even check it in the hook.
>>>>>
>>>>>>> Any other ideas on how to implement this on the server?
>>>>>> What's wrong with one of these methods?
>>>>>>
>>>>>> http://subversion.tigris.org/faq.html#version-value-in-source
>>>>> All of these methods are imlemented in the client side.
>>>>> I have a C# gui developer running visual studio 2005
>>>>> socket programmer developing in GNU make
>>>>> java web programmer developing in NetBeans
>>>>> A solution in the client side would be a hassle for me.
>>>>>
>>>>> What do you suggest ?
>>>> First let me say that if there is a way to do it on the server without
>>> incrementing the revision (2 revision bump as you said), then I don't
>>> know how to do it.
>>>
>>>> That said, I think this is a client side implementation, whether it is
>>>> a
>>> hassle or not. I suppose your team should have a build system -- a
>>> makefile, an ant file (or two) etc. Either you should incorporate the
>>> suggestions in the link (run 'svnversion' and write it into a file etc)
>>> in each of these build files or you should have a driver build file that
>>> drives each build file. And the 'svnversion' thing can be placed only
>>> into the driver build file.
>>>
>>>> Regards,
>>>> -Hari
No, the version.h file would only be changed whenever the project is
built. "version.h" is never checked into the repo and you never have to
worry about updating a number.
No, the other build systems wouldnt use the driver: rather the driver
would call those systems.
A simpler solution is to just have a pre-build script for each project
type that creates version.h from svnversion on each build. You have to
configure it once for each project type, then you can just forget about it.
PS. Think of your suggestion like this: take whatever "problems" or
"hassle" that our solution would cause you, multiply that by 10, add 15
(to make test suites) and thats how much work the svn devs would have to do.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-04 00:14:22 CEST