Guten Tag David Sandberg,
am Mittwoch, 20. März 2013 um 18:17 schrieben Sie:

> > 4) Now, Sam merges trunk revision 200 into his feature branch.  The 
> > merge happens automatically without prompts for conflicts or anything, 
> > and the resulting file A contains MOST of the changes from the trunk 
> > revision ... EXCEPT for the Revision keyword, which stays at 101!
> 
> Those keywords are substituted only by the client after the commit, there are 
> not
> part of the merge and therefore the old values persist until a commit is made.
> During updates the keyword is updated because something has changed for this 
> file,
> but again from the client and the keyword is not part of the data in the repo.

The part of this I am not understanding is that the commit was made by the user 
Jim ... shouldn't that change be a part of the file thereafter? Because at that 
point I can look directly at the contents of the repository (via TSVN's Repo 
Browser) and see the updated revision number has been committed.  It is after 
that point that said revision is merged by Sam into a branch, and the 
already-updated revision # gets lost.

Or are you saying that, when I look at the repository contents afterwards, it 
is my own SVN client that is adding in the revision number for me at that 
point, by looking back to see what the most recent revision of that file is? 
Things I had read elsewhere suggested that the keyword substitution takes place 
on the client during the commit process, but is it actually the case that the 
client only updates the committing user's working copy of that file during the 
commit, and then similarly updates any other user's working copy of that file 
with the same revision number during an update?  If this is the case, then am I 
on the right track by thinking that the revision # of the merged file wouldn't 
be updated because the client doesn't regard a merge as the same thing as an 
update, and the revision # would only be updated when that merged file is 
committed (and to the revision of the merge commit in that branch, not the 
revision of the original trunk modification)?

Thank you for the reply, and for any additional clarification!  (BTW, I have 
read the relevant section of the SVN book several times, and don't seem to be 
able to glean the answers to these behaviors from its contents.)

- David Sandberg

Reply via email to