You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andrew Phillips <ap...@wilcom.com.au> on 2006/07/07 05:17:39 UTC

Modifications lost

I and another developer (on the other side of the globe) have been
making changes to the same source file.  Several times it has happened
that when he commits his changes my recent changes are lost.

For example, 2 days ago he committed the file (revision 117).  I
committed the file twice yesterday (118 and 119).  Last night he made
changes and committed 120.  This contained his recent changes but
reversed my changes made in 118 and 119.  However, after he updated and
committed he created a new .EXE which does include my changes.

He says that he did not intentionally (or unintentionally) remove my
changes, and that he (or another entity) is *not* copying old versions
of files into his working copy.  He also insists that he is updating and
committing correctly, although he did get a "checksum" error recently
while updating the file.

Could this be an SVN bug?  It sounds like a "diff" between 119 and 120
is being generated on his machine and sent to the server, but the server
is applying it to revision 117 instead of 119.  I have done tests and
cannot reproduce what he says is happening.  I can't personally check
what he is doing as he is in Europe and I am in Australia, but he
insists that he is doing nothing wrong.

The SVN server is running locally here on a Windows 2003 server.  He
connects via VPN over the internet.  We are using TSVN but I don't think
that is related to the problem.

apache_2.0.55-win32-x86-no_ssl
svn-1.3.0

Thanks for any advice, Andrew.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


Re: Modifications lost

Posted by Felix Gilcher <gi...@exozet.com>.
Hi,

Am 07.07.2006 9:01 Uhr schrieb "Ulrich Eckhardt" unter
<ec...@satorlaser.com>:

> On Friday 07 July 2006 07:17, Andrew Phillips wrote:
>> I and another developer (on the other side of the globe) have been
>> making changes to the same source file.  Several times it has happened
>> that when he commits his changes my recent changes are lost.
>> 
>> For example, 2 days ago he committed the file (revision 117).  I
>> committed the file twice yesterday (118 and 119).  Last night he made
>> changes and committed 120.  This contained his recent changes but
>> reversed my changes made in 118 and 119.
> 
> If he tried to commit changes that are based on 117, Subversion will refuse
> that and tell him to first update his working copy. Doing so will merge all
> changes up to head into his working copy. If this leads to a conflict, there
> is a simple resolution (using TSVN, as you later mention) to resolve the
> conflict "using theirs" (discarding own changes) or "using mine" (discarding
> all changes pulled from the repository). The right solution is of course to
> edit the conflict by hand, test the code and then commit a merged version. If
> your buddy didn't do that, that's a recipe for losing changes.
> 
> Anyhow, you should lart that guy because using TSVN it's a breeze to get a
> diff before checking in and at latest then he should really see what he's
> checking in. Using a tool is no excuse for not using one's brain.
> 
>> However, after he updated and committed he created a new .EXE which
>> does include my changes.
> 
> Hmmm, now that's strange.
>

Might it be possible that he's keeping the file open in the editor during
the update and that his editor/DIE is so broken that it does not warn that
the file was changed behind his back by svn update? Compiling at that point
would lead to an executable containing the changes and saving the file
followed by a commit would remove the changes again? Even though it's not
impossible that svn does have a bug I'd rather doubt that you'd be the only
one noticing it (or maybe there's something very special about your setup).
 
>> He says that he did not intentionally (or unintentionally) remove my
>> changes, and that he (or another entity) is *not* copying old versions
>> of files into his working copy.  He also insists that he is updating and
>> committing correctly, although he did get a "checksum" error recently
>> while updating the file.
> 
> A checksum error hints at a corrupted working copy, i.e. that someone (him) or
> something (a broken tool) messed with Subversion's metadata which is stored
> in the .svn subdirs. Neither user nor tools should touch anything inside
> those, which is also why they are hidden and read-only.
> 
> Uli
> 
> 

Good luck

felix

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Modifications lost

Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Friday 07 July 2006 07:17, Andrew Phillips wrote:
> I and another developer (on the other side of the globe) have been
> making changes to the same source file.  Several times it has happened
> that when he commits his changes my recent changes are lost.
>
> For example, 2 days ago he committed the file (revision 117).  I
> committed the file twice yesterday (118 and 119).  Last night he made
> changes and committed 120.  This contained his recent changes but
> reversed my changes made in 118 and 119.

If he tried to commit changes that are based on 117, Subversion will refuse 
that and tell him to first update his working copy. Doing so will merge all 
changes up to head into his working copy. If this leads to a conflict, there 
is a simple resolution (using TSVN, as you later mention) to resolve the 
conflict "using theirs" (discarding own changes) or "using mine" (discarding 
all changes pulled from the repository). The right solution is of course to 
edit the conflict by hand, test the code and then commit a merged version. If 
your buddy didn't do that, that's a recipe for losing changes.

Anyhow, you should lart that guy because using TSVN it's a breeze to get a 
diff before checking in and at latest then he should really see what he's 
checking in. Using a tool is no excuse for not using one's brain.

> However, after he updated and committed he created a new .EXE which 
> does include my changes.

Hmmm, now that's strange.

> He says that he did not intentionally (or unintentionally) remove my
> changes, and that he (or another entity) is *not* copying old versions
> of files into his working copy.  He also insists that he is updating and
> committing correctly, although he did get a "checksum" error recently
> while updating the file.

A checksum error hints at a corrupted working copy, i.e. that someone (him) or 
something (a broken tool) messed with Subversion's metadata which is stored 
in the .svn subdirs. Neither user nor tools should touch anything inside 
those, which is also why they are hidden and read-only.

Uli


****************************************************
Visit our website at <http://www.domino-printing.com/>
****************************************************
This Email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any reading, redistribution, disclosure or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please contact the sender immediately and delete the material from your computer.

E-mail may be susceptible to data corruption, interception, viruses and unauthorised amendment and Domino UK Limited does not accept liability for any such corruption, interception, viruses or amendment or their consequences.
****************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org