You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ingo Adler <de...@synacon.ch> on 2005/04/16 07:42:46 UTC
Unnoticed conflicts when moving or deleting
Hi,
I have a big problem with svn - as a former CVS user and in general.
Szenario:
Markus moves a file and commits his changes.
Andreas changes the same file in the mean time, updates and commits.
There is no conflict no, warning - nothing. The changed files of Andreas
are not unter subversion's control anymore - very bad.
Although a conflict happend - both changed the same file in a way that
subversion cannot handle automatically - Andreas will not notice.
He will think everything is fine, but he can hit many problems:
1. His project will get strange compile errors.
or
2. His project will compile - he will get strange runtime errors.
or
3. His project will compile, no strange errors. Because he thinks, that
he finished his work, he gets a clean version. Now his changes are lost.
A couple of weeks later he will get a bug report for bugs he thought he
had fixed.
All these szenarios cost much effort and will ruin his confidence in the
development environment.
This wouldn't happen in CVS. A changed but deleted file is marked as a
conflict, which is probably the best way except defining a new state.
The developers who get conflict, know that they have a problem and that
they have to handle it. They cannot blame their revision control system,
when they spend much time searching for strange bugs or when they loose
code.
What's the solution?
Regards
Ingo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Ingo Adler <in...@synacon.ch>.
Ben Collins-Sussman wrote:
>
> On Apr 16, 2005, at 6:02 PM, Ingo Adler wrote:
>
>>>
>>> It's not marked as a conflict, but the data isn't lost either. The
>>> file becomes unversioned.
>>
>> Information is lost. Is data information?
>
> How is information lost? Subversion certainly isn't losing any
> information. The edited file becomes unversioned, but nothing's
> *deleting* that data.
The file lost its handle to Subversion. You cannot ask it anymore, where
it's gone, who deleted it and so on. I know that you can find the
information somehow. But why should I look for it in the first place.
Don't just think about moving. Think about deletion too. Someone
restructured the code and the changed code moved to another file with
cut and paste.
There is no automatic way to solve this situation. But the developer has
to get a hint, that something important happend.
When the average developer finds the new file, he will add it again,
because he thinks, that either he forgot the file or Subversion lost the
connection somehow.
Or when he doesn't find the new file, he will delete it later (by
getting a clean update or whatever).
In the mean time he will strungle with strange bugs that only he has or
reappearing bugs in the bug reports.
>>>> The developers who get conflict, know that they have a problem and
>>>> that they have to handle it.
>>>
>>> Well, running 'svn status' will show the old file as '?', so there's
>>> still an indication that *something* is new in the working copy.
>>
>> The developer didn't add anything. Why should there be anything new?
>> We have big trees of source files (Java development). We wouldn't
>> know where to run svn status.
>
> Your developers don't run 'svn status' before they commit, to see what
> they're committing? Even GUIs show you what you're about to commit,
> which includes displaying unversioned files.
>
>> Modern IDEs wouldn't notice because either they add your file to
>> Subversion when you create it or they'll ignore it forever.
>
>
> I don't understand what you mean here. Are you saying there's an IDE
> out there which doesn't display unversioned files?
Developers rely on their IDE, which lists the changed files before
committing. The important file is not shown, because it's not under
Subversion control anymore. And if it's shown, he'll probably add it again.
I like simple rules:
When a source file is not under version control - add it.
When there is a conflict - solve it, it can be difficult.
Not:
When a source file is not under version control - ask all your
co-workers, if someone moved or deleted it; check the repositiory, if
that's true; wait a few hours maybe someone will remember later; if you
are really certain add it or solve the conflict.
>>
>> Isn't it a textual conflict too? Someone deleted the whole content of
>> a file - someone else changed a view lines.
>> OK - I know that there is a difference between an empty file and no
>> file. But why is it so important for a conflict?
>>
>
> The problem is that libsvn_wc currently has a narrow definition of a
> conflict: it thinks that a conflict is always the result of trying to
> merge 3 files. Even if there are no conflict markers, it expects to
> create 3 fulltext backup files.
>
> So, one possible solution is to expand the design so that a file can
> be in a state of conflict, yet somehow indicate to the user that the
> server wants to delete the file; that's definitely not the same as
> saying, "the server wants the file to be empty".
>
> Another possible solution is to just have 'svn update' bail out when
> it tries to delete a file that has local edits. It's already bails
> out when it tries to add a file that already exists. Maybe that's
> just the simplest thing to do... in both cases, the user has to move
> the file out of the way before resuming the update.
I like the first solution better. It's proven to work in CVS. If you
really need three files, create them with content that states what
happend ("file xy moved to, or file xy deleted").
The second solution (bailing out) is not as good because the developer
wouldn't know where he should merge his changes because he wouldn't get
the moved file's target.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre-commit hook %CMDCDMLINE%format
Posted by Max Bowsher <ma...@ukf.net>.
Peter McNab wrote:
> While testing a pre-commit hook batch file on NT4 I have encountered an
> unusual looking command line format,
> but it does work.
>
> The batch file reports each commit attempt to a simple log file
>
> @echo off
> set path=%path%;c:\Program Files\Subversion\bin
> Date /T >> D:\pre-commit.log
> Time /T >> D:\pre-commit.log
> @echo %CMDCMDLINE% >> D:\pre-commit.log
> SVNLOOK.exe log -t "%2" "%1" | grep.exe "[a-zA-Z0-9]" > nul || exit 1
> @echo Committed OK >> D:\pre-commit.log
> exit 0
>
> The resultant output looks like this
>
> Sun 17/04/2005
> 2:07a
> C:\WINNT\system32\cmd.exe /C ""D:\svn\SourceTree\hooks\pre-commit.bat"
> D:^\svn/SourceTree 140-1"
> Committed OK
>
> The repository is in the directory D:\svn\SourceTree
>
> So the question is:-
> Is the format of the %CMDCMDLINE% part "D:^\svn/SourceTree" as shown
> expected?
Yes.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Pre-commit hook %CMDCDMLINE%format
Posted by Peter McNab <mc...@melbpc.org.au>.
While testing a pre-commit hook batch file on NT4 I have encountered an
unusual looking command line format,
but it does work.
The batch file reports each commit attempt to a simple log file
@echo off
set path=%path%;c:\Program Files\Subversion\bin
Date /T >> D:\pre-commit.log
Time /T >> D:\pre-commit.log
@echo %CMDCMDLINE% >> D:\pre-commit.log
SVNLOOK.exe log -t "%2" "%1" | grep.exe "[a-zA-Z0-9]" > nul || exit 1
@echo Committed OK >> D:\pre-commit.log
exit 0
The resultant output looks like this
Sun 17/04/2005
2:07a
C:\WINNT\system32\cmd.exe /C ""D:\svn\SourceTree\hooks\pre-commit.bat"
D:^\svn/SourceTree 140-1"
Committed OK
The repository is in the directory D:\svn\SourceTree
So the question is:-
Is the format of the %CMDCMDLINE% part "D:^\svn/SourceTree" as shown
expected?
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Ingo Adler <in...@synacon.ch>.
Ben Collins-Sussman wrote:
>
> On Apr 16, 2005, at 9:24 PM, Branko Čibej wrote:
>
>> Ben, don't you think you're taking a slightly too relaxed view of
>> this bug?
>
>
> Maybe so. I'm not arguing that there's no bug here, there's
> definitely a bug. But on the other hand, we've gotten along for 5
> years with it too, with no huge detrimental results. So I don't feel
> like this is a P-1 fire to put out.
Maybe you have the perfect file layout from the beginning, maybe you
only have first-class developers. We don't have either. So we have to
refactor our code from time to time, which involves moving and deleting
files.
You claim:
"Directories, renames, and file meta-data are versioned.
Lack of these features is one of the most common complaints against CVS.
..."
Maybe CVS doesn't track the history for moves, but it works much better
in this important and difficult situation: conflicts.
>> Let's take a slightly more complex change, where the file gets both
>> renamed and modified in the repository. You update, your local chages
>> become unversioned ... and there's no way to merge the changes into
>> the renamed file without using external diff/patch tools. I call that
>> fundamentally broken.
>
>
> Agreed, the behavior is broken and unfriendly to users. But no data
> is lost. That's what I'm challenging. It may be "mentally lost" in
> the shuffle, but not *actually* deleted.
When a "svn commit" would change the state to "?" in some buggy
situation, would this be a P1?
>> Another possible solution is to just have 'svn update' bail out when
>> it tries to delete a file that has local edits. It's already bails
>> out when it tries to add a file that already exists. Maybe that's
>> just the simplest thing to do... in both cases, the user has to move
>> the file out of the way before resuming the update.
>>
>> This could work, *if* the user could just reproduce the "svn mv"
>> locally and have the next update merge the contents of the renamed file.
>>
>
> Forget about the move scenario, it's just a more complex example of
> the unfriendly deletion behavior. Even if svn had true-moves, and the
> server were able to make libsvn_wc really move things during an
> update, the problem will still exist in the simplest form: that is,
> 'svn up' trying to delete a modified file. That's what we should
> focus on.
Right.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 16, 2005, at 9:24 PM, Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>>
>> On Apr 16, 2005, at 6:02 PM, Ingo Adler wrote:
>>
>>>>
>>>> It's not marked as a conflict, but the data isn't lost either. The
>>>> file becomes unversioned.
>>>
>>>
>>> Information is lost. Is data information?
>>
>>
>> How is information lost? Subversion certainly isn't losing any
>> information. The edited file becomes unversioned, but nothing's
>> *deleting* that data.
>
> Ben, don't you think you're taking a slightly too relaxed view of this
> bug?
Maybe so. I'm not arguing that there's no bug here, there's definitely
a bug. But on the other hand, we've gotten along for 5 years with it
too, with no huge detrimental results. So I don't feel like this is a
P-1 fire to put out.
> Let's take a slightly more complex change, where the file gets both
> renamed and modified in the repository. You update, your local chages
> become unversioned ... and there's no way to merge the changes into
> the renamed file without using external diff/patch tools. I call that
> fundamentally broken.
Agreed, the behavior is broken and unfriendly to users. But no data is
lost. That's what I'm challenging. It may be "mentally lost" in the
shuffle, but not *actually* deleted.
>
>> Another possible solution is to just have 'svn update' bail out when
>> it tries to delete a file that has local edits. It's already bails
>> out when it tries to add a file that already exists. Maybe that's
>> just the simplest thing to do... in both cases, the user has to move
>> the file out of the way before resuming the update.
>
> This could work, *if* the user could just reproduce the "svn mv"
> locally and have the next update merge the contents of the renamed
> file.
>
Forget about the move scenario, it's just a more complex example of the
unfriendly deletion behavior. Even if svn had true-moves, and the
server were able to make libsvn_wc really move things during an update,
the problem will still exist in the simplest form: that is, 'svn up'
trying to delete a modified file. That's what we should focus on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Apr 16, 2005, at 6:02 PM, Ingo Adler wrote:
>
>>>
>>> It's not marked as a conflict, but the data isn't lost either. The
>>> file becomes unversioned.
>>
>>
>> Information is lost. Is data information?
>
>
> How is information lost? Subversion certainly isn't losing any
> information. The edited file becomes unversioned, but nothing's
> *deleting* that data.
Ben, don't you think you're taking a slightly too relaxed view of this
bug? Let's take a slightly more complex change, where the file gets both
renamed and modified in the repository. You update, your local chages
become unversioned ... and there's no way to merge the changes into the
renamed file without using external diff/patch tools. I call that
fundamentally broken.
Now I'm not saying a fix would be trivial, but we should certainly do
something about it.
> Another possible solution is to just have 'svn update' bail out when
> it tries to delete a file that has local edits. It's already bails
> out when it tries to add a file that already exists. Maybe that's
> just the simplest thing to do... in both cases, the user has to move
> the file out of the way before resuming the update.
This could work, *if* the user could just reproduce the "svn mv" locally
and have the next update merge the contents of the renamed file.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 16, 2005, at 6:02 PM, Ingo Adler wrote:
>>
>> It's not marked as a conflict, but the data isn't lost either. The
>> file becomes unversioned.
>
> Information is lost. Is data information?
How is information lost? Subversion certainly isn't losing any
information. The edited file becomes unversioned, but nothing's
*deleting* that data.
>
>>> The developers who get conflict, know that they have a problem and
>>> that they have to handle it.
>>
>> Well, running 'svn status' will show the old file as '?', so there's
>> still an indication that *something* is new in the working copy.
>
> The developer didn't add anything. Why should there be anything new?
> We have big trees of source files (Java development). We wouldn't know
> where to run svn status.
Your developers don't run 'svn status' before they commit, to see what
they're committing? Even GUIs show you what you're about to commit,
which includes displaying unversioned files.
> Modern IDEs wouldn't notice because either they add your file to
> Subversion when you create it or they'll ignore it forever.
I don't understand what you mean here. Are you saying there's an IDE
out there which doesn't display unversioned files?
>
> Isn't it a textual conflict too? Someone deleted the whole content of
> a file - someone else changed a view lines.
> OK - I know that there is a difference between an empty file and no
> file. But why is it so important for a conflict?
>
The problem is that libsvn_wc currently has a narrow definition of a
conflict: it thinks that a conflict is always the result of trying to
merge 3 files. Even if there are no conflict markers, it expects to
create 3 fulltext backup files.
So, one possible solution is to expand the design so that a file can be
in a state of conflict, yet somehow indicate to the user that the
server wants to delete the file; that's definitely not the same as
saying, "the server wants the file to be empty".
Another possible solution is to just have 'svn update' bail out when it
tries to delete a file that has local edits. It's already bails out
when it tries to add a file that already exists. Maybe that's just the
simplest thing to do... in both cases, the user has to move the file
out of the way before resuming the update.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Ingo Adler <in...@synacon.ch>.
Ben Collins-Sussman wrote:
> On Apr 16, 2005, at 2:42 AM, Ingo Adler wrote:
>
>> Szenario:
>> Markus moves a file and commits his changes.
>> Andreas changes the same file in the mean time, updates and commits.
>> There is no conflict no, warning - nothing. The changed files of
>> Andreas are not unter subversion's control anymore - very bad.
>
> This scenario has been described over and over. It's one of our
> classic examples of why subversion needs "true renames" rather than
> copy/delete actions. It's even documented in our merge-tracking
> brainstorm doc, in section C-2:
>
> http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
No - it's not. Maybe when you solve the problems described in that
document my problem is solved too. My problem is not "repeated merging"
and so on.
It's even not "svn merge' needs to track renames better". That would be
a possible solution but not the only one.
CVS doesn't have true renames. It doesn't have this problem either. And
it's merge doesn't track renames at all.
>> This wouldn't happen in CVS. A changed but deleted file is marked as
>> a conflict, which is probably the best way except defining a new state.
>
> It's not marked as a conflict, but the data isn't lost either. The
> file becomes unversioned.
Information is lost. Is data information?
>> The developers who get conflict, know that they have a problem and
>> that they have to handle it.
>
> Well, running 'svn status' will show the old file as '?', so there's
> still an indication that *something* is new in the working copy.
The developer didn't add anything. Why should there be anything new? We
have big trees of source files (Java development). We wouldn't know
where to run svn status.
Modern IDEs wouldn't notice because either they add your file to
Subversion when you create it or they'll ignore it forever.
>> What's the solution?
>
> Either wait for svn to implement true move operations, or start a
> discussion about how libsvn_wc might be able to mark the file
> conflicted. It would require some new design; up till now, 'C'
> always represented textual-conflicts, not tree-conflicts.
Isn't it a textual conflict too? Someone deleted the whole content of a
file - someone else changed a view lines.
OK - I know that there is a difference between an empty file and no
file. But why is it so important for a conflict?
Ingo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unnoticed conflicts when moving or deleting
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 16, 2005, at 2:42 AM, Ingo Adler wrote:
> Szenario:
> Markus moves a file and commits his changes.
> Andreas changes the same file in the mean time, updates and commits.
> There is no conflict no, warning - nothing. The changed files of
> Andreas are not unter subversion's control anymore - very bad.
This scenario has been described over and over. It's one of our
classic examples of why subversion needs "true renames" rather than
copy/delete actions. It's even documented in our merge-tracking
brainstorm doc, in section C-2:
http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt
>
> This wouldn't happen in CVS. A changed but deleted file is marked as a
> conflict, which is probably the best way except defining a new state.
It's not marked as a conflict, but the data isn't lost either. The
file becomes unversioned.
> The developers who get conflict, know that they have a problem and
> that they have to handle it.
Well, running 'svn status' will show the old file as '?', so there's
still an indication that *something* is new in the working copy.
>
> What's the solution?
>
Either wait for svn to implement true move operations, or start a
discussion about how libsvn_wc might be able to mark the file
conflicted. It would require some new design; up till now, 'C' always
represented textual-conflicts, not tree-conflicts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org