Ignore scenario - guidance appreciated.

["Foster, Richard - PAL" <RF...@quixotecorp.com>]

Greetings all,

I have looked through the archives for this mailing list, and I am still
confused about how (or if) certain files in my source repository should
be handled.

The scenario is as follows:

*	We run a continuous integration process. Changes in the source
code (as reported by Subversion) trigger the build.
*	The build script (among other things) updates AssemblyInfo.cs
files. (Yup, it's a C# / .NET project).
*	If the AssemblyInfo.cs files are not in the repository, then it
is not possible for a developer with *just* Visual Studio and Subversion
to get the source and build the project.
*	If the AssemblyInfo.cs files are in the repository, then a
developer running the build script runs the risk of checking in an
updated file. This could cause a problem since it may result in a file
built on a developers machine appear to have been built as part of a
release build, or the continuous integration process (the build machine
is, alas, occasionally used by visiting engineers as a development
machine).

What is the recommended way of dealing with this scenario? Ideally, I
would like to be able to have the AssemblyInfo.cs files in the
repository, but not have Subversion complain or update them if they are
different on a developer's machine (unless explicitly asked to do so).

Re: Ignore scenario - guidance appreciated.

[William Nagel <bi...@stagelogic.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You're correct that there's not really a good way to automatically do 
what you want.

One potential workaround is to check-in the AssemblyInfo.cs files to a 
"template" directory, and then have each developer run a script that 
would copy the files into the proper working directory, that way the 
AssemblyInfo.cs file that was actually used would be unversioned (and 
svn:ignore properties could be set up to ignore it), but the pristine 
AssemblyInfo.cs file would be versioned in a place where changes 
wouldn't accidentally be committed.  Of course, if the AssemblyInfo.cs 
file changes frequently, this might be an error-prone solution, but if 
changes are infrequent it could be workable.

- -Bill


On Mar 28, 2005, at 10:09 AM, Foster, Richard - PAL wrote:

> Greetings all,
>
> I have looked through the archives for this mailing list, and I am 
> still confused about how (or if) certain files in my source repository 
> should be handled.
>
> The scenario is as follows:
> 	∙ 	We run a continuous integration process. Changes in the source 
> code (as reported by Subversion) trigger the build.
> 	∙ 	The build script (among other things) updates AssemblyInfo.cs 
> files. (Yup, it's a C# / .NET project).
> 	∙ 	If the AssemblyInfo.cs files are not in the repository, then it is 
> not possible for a developer with *just* Visual Studio and Subversion 
> to get the source and build the project.
> 	∙ 	If the AssemblyInfo.cs files are in the repository, then a 
> developer running the build script runs the risk of checking in an 
> updated file. This could cause a problem since it may result in a file 
> built on a developers machine appear to have been built as part of a 
> release build, or the continuous integration process (the build 
> machine is, alas, occasionally used by visiting engineers as a 
> development machine).
>
>
>
> What is the recommended way of dealing with this scenario? Ideally, I 
> would like to be able to have the AssemblyInfo.cs files in the 
> repository, but not have Subversion complain or update them if they 
> are different on a developer's machine (unless explicitly asked to do 
> so). From what I have read, I do not believe Subversion would allow me 
> to accomplish this. Do I understand correctly, or have I missed 
> something?
>
> Regards,
>  Richard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCSCWTSwe0AHUdEwQRAgtsAKC3hqv8EXlrj2RAsl+MgDCdAyCqaQCdFtab
VTOzVf3mgTAIwULSGSoJ04g=
=+wqV
-----END PGP SIGNATURE-----


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org