You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2008/04/18 10:05:03 UTC
Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree conflicts)
Enlightenment sought from anybody who can help, on three questions:
* Update is smarter than Merge w.r.t. tree changes
"svn update" can detect whether the object in your WC that it's about to modify
or delete is "the same object" that is the WC BASE object, and can raise a
conflict if it is not (e.g. if it is locally scheduled for replacement).
"svn merge" cannot do this, because it just applies a change to the target
items that matches by pathname, without regard to its object-identity.
This is by design. I just want to check that I understand correctly and that
we're keeping this current definition of "merge". I assume we are not
attempting to make "merge" use historical relationships between source and
target to detect this sort of situation.
* Update: permits adding a file already scheduled for add
subversion/libsvn_wc/update_editor.c: add_file()
/* When adding, there should be nothing with this name unless unversioned
obstructions are permitted or the obstruction is scheduled for addition
without history. */
Why do we allow "update" to add a file that is locally scheduled for
add-without-history? (And why not also add-with-history?)
* Update: silently undeletes a deleted file
subversion/libsvn_wc/update_editor.c: add_file()
/* sussman sez: If we're trying to add a file that's already in
`entries' (but not on disk), that's okay. It's probably because
the user deleted the working version and ran 'svn up' as a means
of getting the file back.
This sounds like something we do only because CVS users got used to doing it.
Normally, "update" only applies changes that have happened in the repository.
It's presumptious to assume that the user didn't actually want the file to go
away (but maybe just forgot to use "svn delete").
I would like to convert this case to a tree conflict. Is there any serious
benefit to not doing so, and keeping this special case?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by Julian Foad <ju...@btopenworld.com>.
Andreas Schweigstill wrote:
> Hello!
Hello Andreas. Thanks for your thoughts.
> Julian Foad schrieb:
>
>> /* sussman sez: If we're trying to add a file that's already in
>> `entries' (but not on disk), that's okay. It's probably because
>> the user deleted the working version and ran 'svn up' as a means
>> of getting the file back.
>>
>> This sounds like something we do only because CVS users got used to
>> doing it. Normally, "update" only applies changes that have happened
>> in the repository. It's presumptious to assume that the user didn't
>> actually want the file to go away (but maybe just forgot to use "svn
>> delete").
>
>
> I don't think that Subversion should assume that a file should be
> removed from the repository if it just had been deleted outside
> Subversion.
I agree. (I didn't suggest it should.)
> I quite often delete a file on the local disk and perform an "svn
> update" in order to be really sure that I get a clean copy from the
> repository. It would be too tedious to use "svn revert" if a directory
> tree contains modified files (which have to be committed later) and
> also modified files which have to be reverted to the clean state.
Why is it too tedious for you to use "svn revert file2 file3 file8" but not too
tedious for you to do what you do, which I'm guessing is something like "rm
file2 file3 file8" followed by "svn update"? The effort looks very similar to me.
> Keep in mind that file deletion could also be a result of some kind
> of build/compile process on the sandbox. In my projects I usually
> try to keep strictly separate directories for source files and
> generated files. In order to be sure to start with a clean environment
> I delete the whole directory structure for generated files and do a
> "svn update". What should "svn revert" do if it finds some files which
> are not versioned? Keep them? Throw them away? The latter would be
> very dangerous if the user just forgot to "svn add" them.
Instead of:
rm -rf TREE
svn update TREE
you can use:
svn update -r0 TREE
rm -rf TREE
svn update TREE
Would that be OK for you?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by Andreas Schweigstill <an...@schweigstill.de>.
Hello!
Julian Foad schrieb:
> /* sussman sez: If we're trying to add a file that's already in
> `entries' (but not on disk), that's okay. It's probably because
> the user deleted the working version and ran 'svn up' as a means
> of getting the file back.
>
> This sounds like something we do only because CVS users got used to
> doing it. Normally, "update" only applies changes that have happened in
> the repository. It's presumptious to assume that the user didn't
> actually want the file to go away (but maybe just forgot to use "svn
> delete").
I don't think that Subversion should assume that a file should be
removed from the repository if it just had been deleted outside
Subversion.
I quite often delete a file on the local disk and perform an "svn
update" in order to be really sure that I get a clean copy from the
repository. It would be too tedious to use "svn revert" if a directory
tree contains modified files (which have to be committed later) and
also modified files which have to be reverted to the clean state.
Keep in mind that file deletion could also be a result of some kind
of build/compile process on the sandbox. In my projects I usually
try to keep strictly separate directories for source files and
generated files. In order to be sure to start with a clean environment
I delete the whole directory structure for generated files and do a
"svn update". What should "svn revert" do if it finds some files which
are not versioned? Keep them? Throw them away? The latter would be
very dangerous if the user just forgot to "svn add" them.
Regards
Andreas Schweigstill
--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree conflicts)
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Apr 18, 2008 at 3:05 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Enlightenment sought from anybody who can help, on three questions:
>
>
[...]
> * Update: permits adding a file already scheduled for add
> subversion/libsvn_wc/update_editor.c: add_file()
>
> /* When adding, there should be nothing with this name unless unversioned
> obstructions are permitted or the obstruction is scheduled for addition
> without history. */
>
> Why do we allow "update" to add a file that is locally scheduled for
> add-without-history? (And why not also add-with-history?)
Well, for historical reasons, "update doesn't send add-with-history"
(except of course, now it does), so we have to make sure that the
"add-without-history" coming from the server doesn't clobber the
add-with-history in the wc. (Why this is OK at all and not a
conflict, dunno. But this explains the inconsistency.)
> * Update: silently undeletes a deleted file
> subversion/libsvn_wc/update_editor.c: add_file()
>
> /* sussman sez: If we're trying to add a file that's already in
> `entries' (but not on disk), that's okay. It's probably because
> the user deleted the working version and ran 'svn up' as a means
> of getting the file back.
>
> This sounds like something we do only because CVS users got used to doing
> it. Normally, "update" only applies changes that have happened in the
> repository. It's presumptious to assume that the user didn't actually want
> the file to go away (but maybe just forgot to use "svn delete").
>
> I would like to convert this case to a tree conflict. Is there any serious
> benefit to not doing so, and keeping this special case?
In theory, 'svn revert' should always be the way to revert your
changes to BASE. However, this doesn't work if you've deleted whole
directories (we'll fix this in the new wc library), so you have to use
svn update to fix those cases instead. Thus people get in the habit
of using svn update to revert any deletion...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and
tree conflicts)
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Apr 18, 2008 at 03:24:20PM +0100, Julian Foad wrote:
> Yes, you're right. At present the code for detecting these WC
> inconsistencies is in the same place as that for detecting conflicts, which
> is making it a bit awkward to keep the two concepts separate. I'm not
> intending to move it to the state-report crawl, but in principle that might
> make sense.
This is one point Erik is addressing in his wc-ng notes,
if I understood correctly (albeit maybe not explicitly).
> (Such WC inconsistencies often consist of a node on disk that's unexpected
> or the wrong type, and then they are called "obstructions". A node missing
> from disk when it's expected to be there is another type.)
>
> I have been wondering whether tree-conflicts work should include detecting
> WC inconsistencies and even flagging them as a (distinguishable) type of
> conflict. Now that you've pointed out that we should be able to detect them
> much earlier, I'm seeing that that's a bad idea.
Yes, we should draw a line here.
> I'll just try to keep the two concepts logically separate for now, and not
> bother about obstructions/inconsistencies yet.
Good. Thanks for making me aware of this, too. It's nice to have
proper terms to use when talking about all this highly confusing
stuff :)
So now we have "tree conflicts", "obstructions", and "inconsistencies".
The latter is the new term of the week.
What muddies the waters a bit is that we actually do consider
obstructions to be tree conflicts, but we shouldn't consider
inconsistencies as tree conflicts (given that there are other
ways to deal with inconsistencies, as Mike pointed out).
--
Stefan Sperling <st...@elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Julian Foad wrote:
>
>> Er... did you read my following paragraph? It said:
>>
>>> I would like to convert this case to a tree conflict. Is there any
>>> serious benefit to not doing so, and keeping this special case?
>
>
> Sorry. What I did was read your mail, then Andreas', then responded to
> your mail. I got my threads crossed somewhere in the middle.
>
>> In other words, yes I agree that making the opposite assumption (that
>> it should be scheduled for delete) would be equally wrong. We can't
>> know what the user wanted, so we should ask the user what to do.
>
>
> By calling that scenario a tree conflict (which would make
> delete-atop-schedule-deleted and delete-atop-missing the same thing),
> aren't you already assuming that missing files were intended for deletion?
Ah, yes, so I am. I am confusing "conflicts" (conflicting version-controlled or
scheduled changes) with inconsistent WC state.
> We can never know what the user intended to do, tree conflicts or not.
> We've chosen to make the user explicitly schedule a file's removal from
> version control.
>
> Now, if our goal is to punt on every unsure situation, and a missing
> file is defined as an unsure situation, then 'svn update' should croak
> well before even contacting the server for the new bits. During the
> state report crawl when it finds missing items, it should just bail
> right there. The ambiguity of the situation doesn't appear because the
> server sent a delete-this-file command -- it appears because the working
> file is missing. Right?
Yes, you're right. At present the code for detecting these WC inconsistencies
is in the same place as that for detecting conflicts, which is making it a bit
awkward to keep the two concepts separate. I'm not intending to move it to the
state-report crawl, but in principle that might make sense.
(Such WC inconsistencies often consist of a node on disk that's unexpected or
the wrong type, and then they are called "obstructions". A node missing from
disk when it's expected to be there is another type.)
I have been wondering whether tree-conflicts work should include detecting WC
inconsistencies and even flagging them as a (distinguishable) type of conflict.
Now that you've pointed out that we should be able to detect them much earlier,
I'm seeing that that's a bad idea.
I'll just try to keep the two concepts logically separate for now, and not
bother about obstructions/inconsistencies yet.
Thanks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
> Er... did you read my following paragraph? It said:
>
>> I would like to convert this case to a tree conflict. Is there any
>> serious benefit to not doing so, and keeping this special case?
Sorry. What I did was read your mail, then Andreas', then responded to your
mail. I got my threads crossed somewhere in the middle.
> In other words, yes I agree that making the opposite assumption (that it
> should be scheduled for delete) would be equally wrong. We can't know
> what the user wanted, so we should ask the user what to do.
By calling that scenario a tree conflict (which would make
delete-atop-schedule-deleted and delete-atop-missing the same thing), aren't
you already assuming that missing files were intended for deletion?
We can never know what the user intended to do, tree conflicts or not.
We've chosen to make the user explicitly schedule a file's removal from
version control.
Now, if our goal is to punt on every unsure situation, and a missing file is
defined as an unsure situation, then 'svn update' should croak well before
even contacting the server for the new bits. During the state report crawl
when it finds missing items, it should just bail right there. The ambiguity
of the situation doesn't appear because the server sent a delete-this-file
command -- it appears because the working file is missing. Right?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by Julian Foad <ju...@btopenworld.com>.
(This is the "update restores a file" special case.)
Julian Foad wrote:
> C. Michael Pilato wrote:
>> Julian Foad wrote:
>>> /* sussman sez: If we're trying to add a file that's already in
>>> `entries' (but not on disk), that's okay. It's probably because
>>> the user deleted the working version and ran 'svn up' as a means
>>> of getting the file back.
>>>
>>> This sounds like something we do only because CVS users got used to
>>> doing it.
[...]
>> I would like to convert this case to a tree conflict.
[...]
Of course we'll have to keep this CVS-compatible behaviour by default, because
it's now expected by very many Subversion users too. However, in terms of
implementation I might be able to move this special case from its current
hard-coded location in the code to a shared "conflict resolver" function.
(And this "conflict resolver" might later become configurable with a
user-selectable policy telling it what to resolve automatically and what to
flag as a conflict, a bit like our "--accept=mine/theirs/..." flag.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Julian Foad wrote:
[...]
>> * Update: permits adding a file already scheduled for add
>> subversion/libsvn_wc/update_editor.c: add_file()
>>
>> /* When adding, there should be nothing with this name unless
>> unversioned
>> obstructions are permitted or the obstruction is scheduled for
>> addition
>> without history. */
>>
>> Why do we allow "update" to add a file that is locally scheduled for
>> add-without-history? (And why not also add-with-history?)
>
> The with/without history inconsistency seems odd. The behavior as it
> stands today sounds like it would be useful in one somewhat common
> scenario:
>
> * you make local changes which include adding new files
> * send those changes to someone else as a patch
> * the other person applies and commits the patch
> * you update atop your still-modified working copy
>
> But I'm not sure that one use-case justifies the risk of effectively
> having your local addition automatically and silently transformed into a
> potentially every-line-touching text mod (in the case where the file
> you've added is nothing like the one someone else added).
Good thoughts. Agreed. And I don't suppose that's the only case which wouldn't
work well in a somebody-else-commits-your-patch scenario without more
special-casing. So we can't see much good reason for this.
>> * Update: silently undeletes a deleted file
>> subversion/libsvn_wc/update_editor.c: add_file()
>>
>> /* sussman sez: If we're trying to add a file that's already in
>> `entries' (but not on disk), that's okay. It's probably because
>> the user deleted the working version and ran 'svn up' as a means
>> of getting the file back.
>>
>> This sounds like something we do only because CVS users got used to
>> doing it. Normally, "update" only applies changes that have happened
>> in the repository. It's presumptious to assume that the user didn't
>> actually want the file to go away (but maybe just forgot to use "svn
>> delete").
>
> Nonsense. It's just as presumptuous to assume that just because a file
> has gone missing from a working copy that the user intended to remove
> that item from version control. We don't automatically add new files
> when unversioned ones show up in a working copy tree, do we? Of course
> not. By the same logic, we shouldn't remove files that go missing from
> disk either.
Er... did you read my following paragraph? It said:
> I would like to convert this case to a tree conflict. Is there any
> serious benefit to not doing so, and keeping this special case?
In other words, yes I agree that making the opposite assumption (that it should
be scheduled for delete) would be equally wrong. We can't know what the user
wanted, so we should ask the user what to do.
Better?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Behaviour of "update" vs. "merge" w.r.t. tree changes (and tree
conflicts)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
> Enlightenment sought from anybody who can help, on three questions:
>
>
> * Update is smarter than Merge w.r.t. tree changes
>
> "svn update" can detect whether the object in your WC that it's about to
> modify or delete is "the same object" that is the WC BASE object, and
> can raise a conflict if it is not (e.g. if it is locally scheduled for
> replacement).
>
> "svn merge" cannot do this, because it just applies a change to the
> target items that matches by pathname, without regard to its
> object-identity.
>
> This is by design. I just want to check that I understand correctly and
> that we're keeping this current definition of "merge". I assume we are
> not attempting to make "merge" use historical relationships between
> source and target to detect this sort of situation.
>
>
> * Update: permits adding a file already scheduled for add
> subversion/libsvn_wc/update_editor.c: add_file()
>
> /* When adding, there should be nothing with this name unless unversioned
> obstructions are permitted or the obstruction is scheduled for
> addition
> without history. */
>
> Why do we allow "update" to add a file that is locally scheduled for
> add-without-history? (And why not also add-with-history?)
The with/without history inconsistency seems odd. The behavior as it stands
today sounds like it would be useful in one somewhat common scenario:
* you make local changes which include adding new files
* send those changes to someone else as a patch
* the other person applies and commits the patch
* you update atop your still-modified working copy
But I'm not sure that one use-case justifies the risk of effectively having
your local addition automatically and silently transformed into a
potentially every-line-touching text mod (in the case where the file you've
added is nothing like the one someone else added).
> * Update: silently undeletes a deleted file
> subversion/libsvn_wc/update_editor.c: add_file()
>
> /* sussman sez: If we're trying to add a file that's already in
> `entries' (but not on disk), that's okay. It's probably because
> the user deleted the working version and ran 'svn up' as a means
> of getting the file back.
>
> This sounds like something we do only because CVS users got used to
> doing it. Normally, "update" only applies changes that have happened in
> the repository. It's presumptious to assume that the user didn't
> actually want the file to go away (but maybe just forgot to use "svn
> delete").
Nonsense. It's just as presumptuous to assume that just because a file has
gone missing from a working copy that the user intended to remove that item
from version control. We don't automatically add new files when unversioned
ones show up in a working copy tree, do we? Of course not. By the same
logic, we shouldn't remove files that go missing from disk either.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand