From users-return-22772-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Wed Jan 21 13:18:54 2015 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7683710EEF for ; Wed, 21 Jan 2015 13:18:54 +0000 (UTC) Received: (qmail 62947 invoked by uid 500); 21 Jan 2015 13:18:52 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 62912 invoked by uid 500); 21 Jan 2015 13:18:52 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 62902 invoked by uid 99); 21 Jan 2015 13:18:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jan 2015 13:18:51 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of philip.martin@wandisco.com designates 209.85.212.177 as permitted sender) Received: from [209.85.212.177] (HELO mail-wi0-f177.google.com) (209.85.212.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jan 2015 13:18:47 +0000 Received: by mail-wi0-f177.google.com with SMTP id r20so25550017wiv.4 for ; Wed, 21 Jan 2015 05:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=x2eCuCeydNrkttnlf8GCrsJ6U3WHnb63qdfhWdJoiuM=; b=WBhE4rGfb/GGAIURdxQL4pbJAs9YXITpbxEAlDavkAHgxcK3eqxawrpZkjpGEWQXuT f7XILdAOJQUAhK6oeWYlyc3hQTZKUs0VdF5HpweUIg1tvy31YK+6gbbcMEz2wgJT0NTh UorCdJzWs54OO4h6rz3fKMgu8kLhFar4sW+RQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=x2eCuCeydNrkttnlf8GCrsJ6U3WHnb63qdfhWdJoiuM=; b=L0RjxGmtHcPR+GFI6nqXbZ6xiUkD7dFY2/vmz5NYBYnzv2g5ZfhhL6bLEwtR1YA5bS RLYWYUqIWVrXJZKDwChcIz0PAHpFGayDQUDgKM9htTjfbrImwOVsMXoA08TSbHL7xkDX urCHcJNev95aInDwfJSO+z72o6BKI7GtqZCkAM3x0OvMVv6loeAaBG2HldSVQ42tibRL w/DoM6APspxNnFdo1RgIhGc1JvscmOx7QEvJEfGk9e0V3i9h98FHsw655CLp6swEMewG 5TiXh2MJ97NuGx7qKwSrbKyrp4xDq2XC9KF90tZyKlmBSoX2Un4iHEH+1bXMmnfuuTMS lNUQ== X-Gm-Message-State: ALoCoQm44cO58UOEt7jNqNlTDSgSIID6G0s8xAFal6QNwlpptCnY8Z1lcqePi23qktf6McOfEBW2 X-Received: by 10.180.88.33 with SMTP id bd1mr56231327wib.10.1421846215341; Wed, 21 Jan 2015 05:16:55 -0800 (PST) Received: from localhost (cpc20-farn7-2-0-cust13.6-2.cable.virginm.net. [86.15.228.14]) by mx.google.com with ESMTPSA id vs8sm25516430wjc.6.2015.01.21.05.16.54 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 21 Jan 2015 05:16:54 -0800 (PST) From: Philip Martin To: Tomasz Grobelny Cc: "users\@subversion.apache.org" Subject: Re: E235000: assertion failed (SVN_IS_VALID_REVNUM(new_revision)) References: <3628782412ae4818b2ff02ea5ecab26b@MWNOOSLWISEXC01.makingwaves.no> <87iog0qqxk.fsf@ntlworld.com> <263ceb14c60643f28d03a14e37bd8432@MWNOOSLWISEXC01.makingwaves.no> Date: Wed, 21 Jan 2015 13:16:54 +0000 In-Reply-To: <263ceb14c60643f28d03a14e37bd8432@MWNOOSLWISEXC01.makingwaves.no> (Tomasz Grobelny's message of "Wed, 21 Jan 2015 12:15:09 +0000") Message-ID: <87egqoqnnd.fsf@ntlworld.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked by ClamAV on apache.org Tomasz Grobelny writes: >> That's failed in the code that runs on the client after the commit >> has succeeded. It appears that the the client is acting as if the >> commit worked on the server but it has not got the newly committed >> revision. If you look at the server/repository did the commit >> succeed? >> > No it didn't - I cannot see the changes on the server (now connecting > to it as TFS repo). The client sends an HTTP MERGE request to make a commit. When the commit is successful the server sends a 200 OK response that includes the new revision number and the client updates the working copy. In your case it seems the server sent a response that the client interpreted as a successful commit but without the new revision number. We would really like to see a network trace of the response. The client may have broken the working copy when it tried to apply the missing revision number. You may have to check out a second working copy, compare to the first and manually transfer the changes to the second working copy. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*