[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Keyword substitutions not being merged correctly

From: David Sandberg <david.sandberg_at_HickoryTech.com>
Date: Wed, 20 Mar 2013 13:24:15 -0500

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
Received on 2013-03-20 19:23:59 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.