Joe
2004-12-02 04:48:18 UTC
Hi!
I'd like to know if there is some way to verify what svn update will do
BEFORE it applies the changes. Here is a scenario: I've updated
several files in the trunk, merged those changes into a branch, and have
a work area with files from the branch, some of which have already been
changed locally (but not committed).
First, I'd like to know what files in the branch are going to be
updated, with or without conflicts, somewhat like a "svn need-update"
command that would only LIST the files to be fetched. With that list
and a list from "svn status" I could easily decide which files I could
safely update since I hadn't touched them, and which ones might have
conflicts. svn list -v shows the revs for each file in the branch and
svn info -R prints information on the working copies, including what
revision they come from, but the format of the first is columnar while
the other is line-by-line for each property, making it hard to compare
the two (even if I limit the output of the second with a contextual
grep). I know that svn log -v will show what files were changed, and in
my simple scenario, even if I hadn't personally done the work in the
trunk and the branch, I could track down the changes prior to applying
them, but I can imagine that in a multi-developer, active environment
that could become rather hairy.
The second issue is what changes will be actually be applied,
particularly when they conflict with my local changes. With a list as
described above, if it showed "U" or "C", I could run svn diff to see
what was the extent of the "damage". I realize that svn update produces
an annotated merged version and keeps the old copy (.mine) as well as
the two versions in case I don't like the merged version. However, svn
appears to get confused if I decide to revert, either manually or using
the svn command. svn revert wipes out everything and instead of
restoring my original local copy, it goes back to the original rev in
the branch. If I kept a copy of my changes and use that to overwrite
the original rev, svn update then refuses to merge changes again
(stating it's at head revision). If I rename the .mine file to
overwrite the merged version, svn status still thinks it has a conflict.
I'm using 1.0.6 so maybe this confusion has been fixed in a later
version. Nevertheless, a mechanism for previewing the possible
conflicts without actually updating the files seems like a useful feature.
Joe
I'd like to know if there is some way to verify what svn update will do
BEFORE it applies the changes. Here is a scenario: I've updated
several files in the trunk, merged those changes into a branch, and have
a work area with files from the branch, some of which have already been
changed locally (but not committed).
First, I'd like to know what files in the branch are going to be
updated, with or without conflicts, somewhat like a "svn need-update"
command that would only LIST the files to be fetched. With that list
and a list from "svn status" I could easily decide which files I could
safely update since I hadn't touched them, and which ones might have
conflicts. svn list -v shows the revs for each file in the branch and
svn info -R prints information on the working copies, including what
revision they come from, but the format of the first is columnar while
the other is line-by-line for each property, making it hard to compare
the two (even if I limit the output of the second with a contextual
grep). I know that svn log -v will show what files were changed, and in
my simple scenario, even if I hadn't personally done the work in the
trunk and the branch, I could track down the changes prior to applying
them, but I can imagine that in a multi-developer, active environment
that could become rather hairy.
The second issue is what changes will be actually be applied,
particularly when they conflict with my local changes. With a list as
described above, if it showed "U" or "C", I could run svn diff to see
what was the extent of the "damage". I realize that svn update produces
an annotated merged version and keeps the old copy (.mine) as well as
the two versions in case I don't like the merged version. However, svn
appears to get confused if I decide to revert, either manually or using
the svn command. svn revert wipes out everything and instead of
restoring my original local copy, it goes back to the original rev in
the branch. If I kept a copy of my changes and use that to overwrite
the original rev, svn update then refuses to merge changes again
(stating it's at head revision). If I rename the .mine file to
overwrite the merged version, svn status still thinks it has a conflict.
I'm using 1.0.6 so maybe this confusion has been fixed in a later
version. Nevertheless, a mechanism for previewing the possible
conflicts without actually updating the files seems like a useful feature.
Joe