(snip)
> I'm getting confused with all of the generic terms so here's
> a concrete transcript
Now I'm getting confused... I'll try to decipher this... I'm not trying to
argue, just understand the issues and try to propose a methodology to
implement the feature that is consistent and understandable.
> trunk @ r1000 - timestamp Jan 1 9:00am
> copy trunk to branches/my-branch @ r1001 - timestamps still
> Jan 1 9:00am trunk/fileA changed @r1002 - timestamp Jan 2
> 9:00 am . . .
> branches/my-branch/fileA changed @r1100 - timestamp Jan 10 9:00 am
> (whether this was achieved with svn merge, or manual patch
> the contents of the branch fileA and trunk fileA are now
> identical) . . .
> - merge branch into trunk
> trunk/fileA == branches/my-branch/fileA (file contents
> identical) timestamp trunk Jan 2 != timestamp branch Jan 10
>
> How do you resolve which one is right. In the website update
> use-case you would want the earlier one to avoid uploading
> the file again, but in a make base build environment you
> would want to err on the side of re-building and take the
> later time. The problem is that svn does not track merging so
> there is no way it can know how the two files became identical.
If I understand the above case correctly:
1) you're copying a file from trunk to branch.
2) The trunk is changed on Jan 2.
3) The branch is changed on Jan 10 to be identical with trunk.
We now have two identical files, but with different timestamps in the trunk
and branch.
4) Mege branch into trunk.
At this point I'd expect the new feature to update the trunk timestamp to
Jan 10, to reflect the later date in the branch.
Yes, this may require an "unnecessary" transfer, depending on the smartness
of the update function but it's also "the right thing".
It doesn't matter why or how the trunk and branch got to be identical but
with different time stamps - it's just a regular conflict merge, and in this
case there happenstance is no data difference, but the later timestamps wins
the conflict of timestamps.
>
> or how about this use case
>
> trunk @ r1000 - timestamp Jan 1 9:00am
> copy trunk branches/my-branch @ r1001 - timestamps still Jan 1 9:00am
>
> branch/fileA changed @r1002 - timestamp Jan 2 9:00 am
> ( feature related change )
> . . .
> branch/fileA changed @r1005 - timestamp Jan 3 9:00 am
> ( bug found and fixed )
> . . .
> trunk/fileA changed @r1100 - timestamp Jan 10 9:00 am
> (bug fix from fileA@r1005 merged into trunk) . . .
> Jan 15 - feature work finished - merge branch into trunk
> trunk/fileA != branches/my-branch/fileA (file contents
> different due to r1002), but timestamp on trunk > timestamp
> on branch.
>
> Here you can't keep either timestamp, but you have to use a
> new one. Or, since the changes in the trunk version are a
> subset of the changes in the branch would you keep the branch
> timestamp?
In this case, the "bug fix from fileA@r1005 merged into trunk" would
represent an edit of fileA, and thus update the timestamp on the trunk to
that time, i.e. Jan 10.
I may have gotten lost here, but if nothing else happens than what is given
above with fileA, there are only two manual edits, those @r1002 and @r1005,
thus the merge @r1100 will make both the trunk and branch fileA identical,
and the timestamp should be Jan 3, the same as is now in the branch and both
the trunk and the branch are identical both timestamp and contents.
>
> and
>
> Consider a person who was working on the branch, when they
> svn switch to the trunk does that mean all of their
> timestamps change, even though there is no difference in the
> files, triggering a massive rebuild?
Why would the timestamps change more than necessary? From what I understand
the effect of SVN Switch should be identical to doing a fresh checkout, it's
just a shortcut to not move so much data around.
If the trunk has files with contents changed, then they get updated with SVN
switch. The same should apply to the timestamps of course. If the somewhat
unusual case appears where the trunk in this case has files with identical
content but updated timestamps (because someone did "touch" and then commit
perhaps), then the correct thing is indeed to update the timestamps, and
this is regardless of if done through switch or checkout.
(snip)
> It would have to be file properties, because the revision
> date could encompass many different file timestamp changes,
> but the timestamps would only change at commits. Since these
> are properties for each file, that do not correspond directly
> with a specific revision property, but can only change when a
> new revision is created then that is what file properties
> are. They can have special behavior just like svn:executable
> does. I not sure why you don't think this is natural.
I was just trying to be open to others opinions of "magical" things, but as
you point out, svn:executable is perhaps already a case of special behavior.
If so file properties are probably indeed the right mechanism. That's
perfectly ok with me.
> It's just not something you would really explicitly set, but
> would let the client actions manage it for you. If you needed
> to override or fix it that's fine. Same with things like
> svn:author, normally no one changes those and they are
> treated as "special" when it comes to setting them on transactions.
Indeed, the client actions on the server should be the only thing changing
these properties.
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 20 22:35:40 2005