(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...
Nothing is really simple, but it's quite manageable so far.
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?
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 17:25:03 2005