Ulrich Eckhardt wrote:
> 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.
Sorry I should have mentioned there were no conflicts. (We were working
on very different parts of the code.)
> 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.
Good point. He probably didn't do a diff, if he even knew how to do it.
I will make sure he does it next time.
Felix Gilcher wrote:
> 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).
I think that is very likely the problem. I know Delphi does not always
tell you if a file you have open is modified externally. I'll check and
report back. Thanks.
Andrew.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 7 10:12:01 2006