Greg Thomas wrote:
> On Tue, 29 Aug 2006 15:38:22 +0100, "Andrew Webb"
> <andrew.microi@gmail.com> wrote:
>
>
>>> 1-Aug: Alice checks out file foo.c, modification date 1-Aug.
>>> 2-Aug: Bob modifies, commits foo.c
>>> 3-Aug: Alice does a make. foo.c is compiled,
>>> creating foo.o timestamped 3-aug.
>>> 4-Aug: Alice does a 'svn update'. foo.c arrives timestamped 2-Aug
>>> Alice does a make. foo.c is not compiled, despite being
>>> changed since the last compilation, as foo.c is timestamped
>>> 2-Aug (when Bob made the change), which is before foo.o was
>>> created (3-Aug).
>>>
>> I understand.
>>
>> But shouldn't Alice have done an 'svn update' on the 3rd as well?
>>
>
> No. If she was working on a different bug fix to Bob, then there's no
> need for her to do a 'svn update' before each compile. Imagine the
> times I gave above where a minute apart rather than 1 day - I only
> used a day to make it easy to write. The problem still happens.
>
> Greg
>
I'm following this thread with great interest, because maybe I have a
problem I didn't know I had. Here's how I understand it
Alice modifies foo.c on 1-Aug.
She builds on 3-Aug.
She updates on 4-Aug, and either gets a conflicted file foo.c or throws
away her changes from 1-Aug. In either case, doesn't SVN tell her that
a file is updated or conflicted?
If the last-modification date is the "last-edited" date (2-Aug) then
foo.c is not recompiled when Alice makes.
If the last-modification date is the "checked-out" date (4-Aug) then
Alice's build will recompile foo.c, which sounds like it's what Alice wants.
Alice is in trouble because Bob committed before she built. If he had
committed after Alice built, she'd have no problem -- the
last-modification date would not matter either way. But she can't know
for certain unless she checks all the timestamps vs. the repository records.
If the last-modification time is the "checkout/update time", then the
updated files are always newer and a make will update the files. If
it's the"last-edited" time, it can give rise to this uncertain
situation. So I think this argues in favor of "last-checkout time"
instead of "last-edited time" from the standpoint of getting make to do
the right thing. It avoids having to 'touch' the files on checkout.
If I'm missing something, I ask forbearance, and for someone smarter to
set me straight.
I notice that in my repository, the date on the file is different from
what's in my working copy (I suppose it's the last-checked-in date in
the repo). Maybe we should be asking for a last-edited-date property
that can be set when a file is checked in? That way,
the last-modified-date can remain as is to help the make utility rebuild
changed files;
the last checked-in date can be in the repo for history, and
the new property can capture the edit date completely apart from what we
use to control rebuilds. Regardless of whether a file is older or
newer, if it's _different_ I want to rebuild it.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 20:16:14 2006