On 04/03/2008, James Schneider <jim.schneider_at_gmail.com> wrote:
> I'm using TortoiseSVN v1.4.8 on a Ruby-on-Rails project. The repository is
> hosted by CVSDude.com, an Australian company that specializes in source-code
> hosting. My working copy reflects HEAD of a branch. To merge in changes
> from /trunk, I had tsvn compute the change-set between the last-merged
> revision and the latest /trunk and apply it to the working copy of the
> branch. This appears to succeed.
>
> After resolving conflicts, I commit the branch back to the repository. The
> commit processes through to the end but then I get three error messages:
> - Commit succeeded, but other errors follow:
> - Error bumping revisions post-commit (details follow):
> - Directory
> '#{working-copy-root}\vendor\plugins\acts_as_authenticated\generators\authenticated_migration'
> is missing
>
> I found
> 'vendor\plugins\acts_as_authenticated\generators\authenticated_migration'
> in the tsvn commit activity listing. It was listed with action "Deleting".
>
> Then the working copy is rendered unrecoverably unusable. Update fails
> claiming that the top-level directory in the working-copy is locked and that
> I have to run 'cleanup'. Cleanup fails with a pop-up box claiming:
>
> {{{
> Subversion reported an error while doing a cleanup!
> ----
> In directory
> '#{working-copy-root}\vendor\plugins\acts_as_authenticated\generators'
> Error processing commend 'committed' in
> '#{working-copy-root}\vendor\plugins\acts_as_authenticated\generators'
> Working copy
> '#{working-copy-root}\vendor\plugins\acts_as_authenticated'
> locked
> }}}
>
>
> I went to 'vendor\plugins' and noticed that some of the other changes
> produced by the merge are not marked as committed but the changes to
> 'vendor\plugins\acts_as_authenticated' are all represented
> correctly by the shell-integrated tsvn UI.
>
> Then I checked-out a fresh working copy. On first glance, it represents all
> files in the appropriate state.
>
> The revision-number-bumping error actually seems to be reproducible. I've
> done this merge once before, a little differently. Before the merge attempt
> described above, I had the branch with trunk merged-in but not committed
> sitting around for over a week. I committed the changes and performed
> another merge over the more-recently committed work in trunk. On the commit
> of the second merge, my working copy was rendered unusable and the committed
> result was actually missing some of the files from trunk (which I discovered
> when I did a dry-run merge of the updated branch back into trunk and saw
> some inappropriate deletes). At that point, it looked like everything had
> gone haywire. I deleted the post-merge branch and copied the pre-merge
> branch revision up to HEAD so I could try again.
>
> I have just started the merge-back into trunk and have encountered some
> unusual difficulties. I will post a reply to this report if my pending
> merge (of the updated branch back to into trunk) yields any new information.
Do you have a virus scanner running. They are known to cause problems
by holding on to file handles when they shouldn't. Failing that, try
reporting this on the users at subversion.tigris.org mailing list as
the problem appears to lie within the subversion library. TSVN 1.4.8
is linked to subversion 1.4.6 libraries.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-03-05 10:07:19 CET