Am 07.07.2006 9:01 Uhr schrieb "Ulrich Eckhardt" unter
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 7 09:31:35 2006