Dear Ryan,
thank you very much for your instant reply to my message.
Ryan Schmidt wrote:
> Presumably HEAD is greater than 123. Let's say it's 500. "svn co $URL"
> therefore means "check out revision 500 of $URL". You can now happily
> make changes to the working copy and check them in if you like.
Checking them in depends on the state of the head revision, so probably
there has to be performed a svn update.
> "svn co -r123 $URL" means "check out revision 123 of $URL". "svn merge
> -r123:HEAD $URL" (note that you need to tell svn merge what path to
> merge from -- $URL here)
It doesn't have to be a URL; so let's say "svn merge -r123:HEAD $SOURCE"
where source can either be an URL or a working copy path. This is usage
"3" of svn merge (see svn help merge).
> means "now perform local modifications equal to
> the modifications that occurred on $URL between revisions 123 and 500".
> After the merge, Subversion forgets that the local modifications
> occurred due to a merge; to Subversion, the modifications look like any
> other local modification, for example like those you would make by hand.
No, it's not the same because Subversion stores information about the
merge which can be retrieved with "svn info". Let's take the example
from my previous message. File "b" has been created by "svn merge", but
an "svn update" hasn't been performed.
Here you can see the difference in the information stored by Subversion.
aschweig@simpson:~/svntest/test_merge> touch c
aschweig@simpson:~/svntest/test_merge> svn add c
A c
aschweig@simpson:~/svntest/test_merg> svn info b c
Path: b
Name: b
URL: svn://simpson/test/b
Repository Root: svn://simpson/test
Revision: 1
Node Kind: file
Schedule: add
Copied From URL: svn://simpson/test/b
Copied From Rev: 2
Last Changed Author: aschweig
Last Changed Rev: 2
Last Changed Date: 2006-07-31 11:26:01 +0200 (Mon, 31 Jul 2006)
Text Last Updated: 2006-07-31 13:24:29 +0200 (Mon, 31 Jul 2006)
Checksum: cdac10d71fc7dc8b8064ac9dbbf3f743
Path: c
Name: c
URL: svn://simpson/test/c
Repository Root: svn://simpson/test
Revision: 0
Node Kind: file
Schedule: add
===================== CUT HERE ===========================
> Now you cannot commit your working copy for two reasons: a) it is not
> up-to-date, and b) the modifications that have not yet been committed
> are modifications which already exist in the repository, therefore to
> not make sense to commit again.
And it isn't possible to get an up-to-date state. Unfortunately svn
doesn't seem to be able to detect that there hasn't been made any
modification.
> However: the following two commands are equivalent to the original
> checkout; perhaps that's what you're looking for:
>
> svn co -r123 $URL
> svn up -rHEAD (the same as just "svn up")
I have reduced my current problem which occured in much more complicated
merging and patching also from other sources to this very tiny script.
After several tests I finally found a solution which used "svn update"
instead of "svn merge".
The same problems should occur if "svn merge" will be used for merging
branches back to the trunk or to other branches. In such cases probably
"svn switch" can be usefull.
With best regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 31 14:06:39 2006