Hi,
> OK, but how would having these files in version control have caught this
> problem unless you bothered to look at the diffs before checking them in?
Yes I always check the diffs and in fact most UIs (eg sourcetree) show you the
diffs before checking in.
> I wouldn't have noticed by reading
On 2/24/14 10:36 PM, "Justin Mclean" wrote:
>Hi,
>
>> But the changes you are hoping to track are really results of properly
>> changing something else that generates the version files?
>
>No in this case the regular expression in the build file was wrong as it
>assumed single digit version num
Hi,
> But the changes you are hoping to track are really results of properly
> changing something else that generates the version files?
No in this case the regular expression in the build file was wrong as it
assumed single digit version numbers. So the generated files changed without
any chan
On 2/24/14 10:11 PM, "Justin Mclean" wrote:
>Hi,
>
>> This still seems funny to me. Why should a generated file be in version
>> control?
>
>So you can see that it has changed and more importantly what's changed
>inside it. That way you can instantly see that a release candidate is
>broken wit
Hi,
> This still seems funny to me. Why should a generated file be in version
> control?
So you can see that it has changed and more importantly what's changed inside
it. That way you can instantly see that a release candidate is broken without
have to run extra tests (manual or otherwise).
T
On 2/24/14 3:58 PM, "Justin Mclean" wrote:
>And yet again we run into an issue with files that are not in source
>control (Version.as files are modified on the fly and version.properties
>files generated). And this is despite having an RC out for several weeks
>where no one noticed. Anything t
