On 10/5/06, Reedick, Andrew <Andrew.Reedick@bellsouth.com> wrote:
[ snip scenario for creating replace with history working copy item ]
> >
>
> That looks like a bug that was supposedly fixed in 1.4.0. If you delete
> and add a file, the commit will fail. I've occassionally had this
> problem when doing merges using 1.3.x.
Yes, it is. I'd like to point out that the only way to fsck your
working copy this way (in versions older than 1.4) is by using merge:
normal working copy commands won't allow one to create a situation
like this.
The problem here is that a versioned item is replaced with another
item which already has history in the repository (=
replace-with-history). Normal replacements (new item is added to
version control; no history) were never a problem.
> The commit still fails if you revert the file. The workaround I used
> was to commit every file but the R's.
> 1. run 'svn status' and save the output to a file (status.log).
> 2. Save status.log somewhere safe.
> 3. Copy status.log to a new name (filelist.txt). (Keep status.log for
> step 6.)
> 4. Delete any lines in filelist.txt with a status of 'R' (or '?').
> Remove the status codes so you have just filenames remaining.
> 5. svn commit -m "..." --targets filelist.txt
> 6. Create a new workspace and 'merge' the 'R' files manually (don't use
> 'svn merge'). Refer to status.log for the 'R' files.
>
> Or use a 1.4.0 client to do the merge.
Absolutely the best way to resolve the issue, now and in the future
(use 1.4), but beware of the working copy upgrading that happens when
you access the old working copy with the new client. Also see the
release notes.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 5 19:58:18 2006