kfogel@collab.net wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>Now I'm getting scared. We don't have the tools to handle this. Your
>>diff is against r18463, and HEAD is r18468, and 17 files have been
>>changed in that time.
>
> Oh, you don't think I'd just commit the old patch, do you? I updated
> my tree and re-ran the entire process. That's why they call us
> "programmers" :-).
No, that's not what I meant at all. Sorry, I didn't realise that it would read
like that. I quoted those numbers just to describe a reproducible scenario in
which I encountered the conflicts I described next. In my scenario, the
space-change was the local change and those 17 changes came from the
repository; I assumed the result would be similar when 17 files are locally
changed and the space-change comes from the repository.
>>* "svn up" to ignore whitespace. Anyone? Also, how important is
>>this? It's pretty much essential unless all developers have clean WCs
>>at the time they update to this particular revision. There is a
>>particular danger in that there is no automated way to revert an "svn
>>update" that suffers conflicts.
>
> Nah, no danger, conflicts save all possible versions of the files, so
> the user has everything needed for resolution.
Oh, so they do! OK, on an individual file basis I was wrong - you can just
copy back the ".mine" versions of the conflicted files. Also, from trying it
for real (below) it seems the result isn't as bad as I feared.
> Anyway, too late, r18471. It's not like we didn't know what we were
> getting into.
Yikes! OK...
Well, let's see what happens in practice.
$ svnversion .
18463
# Let's have some realistic local changes
$ patch < sort.patch
patching file subversion/libsvn_client/commit.c
patching file subversion/libsvn_client/export.c
patching file subversion/libsvn_client/prop_commands.c
patching file subversion/libsvn_repos/delta.c
patching file subversion/libsvn_wc/adm_crawler.c
patching file subversion/libsvn_wc/adm_ops.c
patching file subversion/libsvn_wc/diff.c
patching file subversion/libsvn_wc/entries.c
patching file subversion/libsvn_wc/status.c
patching file subversion/svn/propget-cmd.c
patching file subversion/tests/cmdline/diff_tests.py
patching file subversion/tests/cmdline/stat_tests.py
# Update past this space change
$ svn update
[...]
U subversion/libsvn_fs_fs/err.h
U subversion/libsvn_fs_fs/lock.h
U contrib/client-side/psvn/psvn.el
Updated to revision 18475.
$ svn status -q
C subversion/libsvn_wc/diff.c
C subversion/libsvn_wc/entries.c
C subversion/libsvn_wc/adm_crawler.c
C subversion/libsvn_wc/adm_ops.c
C subversion/libsvn_wc/status.c
C subversion/libsvn_client/export.c
C subversion/libsvn_client/prop_commands.c
C subversion/libsvn_client/commit.c
M subversion/tests/cmdline/diff_tests.py
M subversion/tests/cmdline/stat_tests.py
C subversion/libsvn_repos/delta.c
C subversion/svn/propget-cmd.c
# Nearly all of my changed files conflicted. That looks daunting.
# Tackle the first conflicted file.
$ ls subversion/libsvn_wc/diff.c*
-rw-r--r-- 58877 2006-02-16 05:11 subversion/libsvn_wc/diff.c
-rw-r--r-- 59021 2006-02-16 05:11 subversion/libsvn_wc/diff.c.mine
-rw-r--r-- 58214 2006-02-15 17:45 subversion/libsvn_wc/diff.c.orig
-rw-r--r-- 58742 2006-02-16 05:11 subversion/libsvn_wc/diff.c.r18463
-rw-r--r-- 58168 2006-02-16 05:11 subversion/libsvn_wc/diff.c.r18475
-rw-r--r-- 2523 2006-02-15 21:34 subversion/libsvn_wc/diff.c.rej
-rw-r--r-- 60236 2006-02-10 00:11 subversion/libsvn_wc/diff.c~
# OK, so I can either resolve the conflicts where marked within the file (and
in fact there aren't as many, or the chunks aren't as big, as I feared they
would be) or I can build the file back from the saved versions of it (.mine,
.r18463, .r18475).
# Now I've resolved all of those 10 files, in about 40 minutes, by editing them
and looking for the conflict markers.
# Later I will look for space-before-paren in non-conflicting (i.e. added)
parts of my local changes.
OK, it was not as bad as I thought it would be. An "svn update" that ignored
space changes would have been lovely, but never mind.
I'd still advise everyone to at least save a diff of your local changes before
updating today, so that you can recover easily if it leaves a big mess
(basically if your local changes are extensive).
> Adjusting outstanding patches to meet the new codebase
> should be pretty trivial, though.
Yes.
Well, good on you for getting this over and done with.
:-)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 16 07:27:56 2006