On 8/20/05, Svante Seleborg <svante@axantum.com> wrote:
> (snip)
> > Why would that be? If I merge something from one branch
> > (trunk) to another, there is nothing that says that the two
> > files (as in text/code/etc) will now be identical. I just
> > merged the changes from that one branch into the other and
> > thus the two files may still not be the same. Would not the
> > timestamp of the newly merged file be the time at which I did
> > the merge? Just as if I hand edited those changes into the file?
> (snip)
>
> You're right. In this case it's the time of the merge that would be set as
> the timestamp in the result of the merge, unless the merge indeed did
> produce an identical file. In that case the timestamp of the merged result
> would be the same time as the merged from file, unless the timestamp of the
> target of the merge was more recent...
>
I'm getting confused with all of the generic terms so here's a
concrete transcript
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.
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?
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?
> Nothing is really simple, but it's quite manageable so far.
>
The first is a common use case, and the second a not quite so common,
but not necessarily rare one. The desired behavior depends on what you're doing
with the repository.
> The only real "challenge" I've seen so far in this discussion is where/how
> to actually store the time-stamp in the repository. The problem being that
> storing it as a regular property doesn't seem like a good idea, and isn't
> right either. Propertys are meta-data that are attached to the data and
> repository specific, but the time-stamp is conceptually external to the
> repository and should live a life on it's own, and should not be versioned
> as such.
>
> I'd think that using the general method of property strong, but marking it
> as "magical" is the easiest way, but might not be clean and elegant enough.
> Anyone with a good suggestion of how to represent the time-stamps in the
> repository?
>
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.
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.
Again, I want to say I'm not trying to argue against this feature,
just trying to
help flesh out the design.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 20 20:24:40 2005