[PATCH] depth test case: unversioned & modified items left untouched when folded

["Rui, Guo" <ti...@mail.ustc.edu.cn>]

Hi,

This will be my last test case for deselection interface of sparse-directory.
I'll dig into update editor code, in which the functionality would most likely
be implemented, in the next step.

[[[
Add test case to verify that folding a subtree will not destroy to content of
unversioned & modified items.

* subversion/tests/cmdline/depth_tests.py
  (fold_tree_with_unversioned_modified_items): New tests.
  (test_lists): Run it XFail
]]]

If we consider the unversioned & modified items as obstructions, should we
make the folding behavior under control of the --force option? That is to say,
only un-version the modified items when forced, just fail the folding by
default. If this is the preferred behavior, a --force option should be passed
to run_and_verify_update() function.

And there is one more problem: should we output 'D ' on items that is
unversioned rather than deleted? When I first asked about folding a modified
item some days ago, Karl figured out that it should act like 'svn delete' --
leave the modified files in place. However, when I tried to see what does 'svn
delete' output in this situation, I found that it either refused to continue
or was forced to delete it. Any suggestion?

Thanks
Rui, Guo

Re: [PATCH] depth test case: unversioned & modified items left untouched when folded

[Karl Fogel <kf...@red-bean.com>]

Karl Fogel <kf...@red-bean.com> writes:
> But in your working copy, you've modified A/D/G/pi, and created an
> unversioned file at A/D/H/unversioned.txt.  When the update arrives, it
> will remove everything else, but it will leave the modified file and the
> unversioned file, and it will (of course) leave parent directories in
> place as necessary to reach those remaining items.

I forgot to add that, in 'svn up', those parent directories will be made
unversioned too -- they just become a skeleton tree to hold the places
of the items that can't be removed.

-Karl

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

Re: [PATCH] depth test case: unversioned & modified items left untouched when folded

[Karl Fogel <kf...@red-bean.com>]

"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> Then, the situation is degenerated to a solved situation. The --force option
> is already prepared for this situation -- the modified file will be
> re-versioned as local modification. I've tested this and verified that it
> works well with --set-depth option, at least for a simple situation. So I
> didn't bother to include it in the test case (In fact, the modification to
> A/mu was original prepared for this test).

Wow -- I didn't even know (or remember) we'd done that.  Great.

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

Re: [PATCH] depth test case: unversioned & modified items left untouched when folded

["Rui, Guo" <ti...@mail.ustc.edu.cn>]

On Tue, Apr 22, 2008 at 11:09:39AM -0400, Karl Fogel wrote:
> > However, the difference between receiving deletion in repository and
> > folding local wc directory should still be taken into account. The
> > flag 'D' is traditionally used to represent deletion that is (or will)
> > reflected in repository. However, I currently expect a 'D ' output in
> > the test cases even if the deletion happens only in local wc when
> > folding. This deserves a second thought. Moreover, when making
> > modified items unversioned rather than removed in this test case, I
> > still use the 'D' flag in expected_output. I doubt if it is a proper
> > way.  Do we need to introduce a new flag for this?
> 
> I think we can just do it silently, exactly the way 'update' would.
I manually checked the output of svn up again. Update will notify each
item deleted in repository with a 'D'. An item of kind directory represent the
whole sub-tree rooted at it. So the expected_output in my folding test case
should be tuned accordingly, a single 'D' should be enough.

Let's check it a second time, the 'D' is ok for even local deletion that is
not reflected in repository.

> 
> The real challenge will come when we unfold such a directory tree back
> to a deeper depth.  Then will we get "obstructed path" errors, when
> preserved modified files are re-versioned?

Then, the situation is degenerated to a solved situation. The --force option
is already prepared for this situation -- the modified file will be
re-versioned as local modification. I've tested this and verified that it
works well with --set-depth option, at least for a simple situation. So I
didn't bother to include it in the test case (In fact, the modification to
A/mu was original prepared for this test).

Rui, Guo

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

Re: [PATCH] depth test case: unversioned & modified items left untouched when folded

[Karl Fogel <kf...@red-bean.com>]

"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
>> But in your working copy, you've modified A/D/G/pi, and created an
>> unversioned file at A/D/H/unversioned.txt.  When the update arrives, it
>> will remove everything else, but it will leave the modified file and the
>> unversioned file, and it will (of course) leave parent directories in
>> place as necessary to reach those remaining items.
>
> Emmm. I admit that I didn't considered this situation. It's very
> similar with the situation here. So don't bother to interfere with the
> --force option since we already chose not to do so in a similar situation.

Exactly -- I agree.

>> That is the behavior I was proposing here: we should fold up all
>> versioned and unmodified stuff, but leave behind anything unversioned or
>> modified (and therefore leave the intermediate directories necessary to
>> reach those items).
>
> Yes, I got your idea even you didn't used a proper example. ;)

Thanks :-).

> However, the difference between receiving deletion in repository and
> folding local wc directory should still be taken into account. The
> flag 'D' is traditionally used to represent deletion that is (or will)
> reflected in repository. However, I currently expect a 'D ' output in
> the test cases even if the deletion happens only in local wc when
> folding. This deserves a second thought. Moreover, when making
> modified items unversioned rather than removed in this test case, I
> still use the 'D' flag in expected_output. I doubt if it is a proper
> way.  Do we need to introduce a new flag for this?

I think we can just do it silently, exactly the way 'update' would.

The real challenge will come when we unfold such a directory tree back
to a deeper depth.  Then will we get "obstructed path" errors, when
preserved modified files are re-versioned?

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

Re: [PATCH] depth test case: unversioned & modified items left untouched when folded

["Rui, Guo" <ti...@mail.ustc.edu.cn>]

On Mon, Apr 21, 2008 at 12:46:27PM -0400, Karl Fogel wrote:
> > If we consider the unversioned & modified items as obstructions, should we
> > make the folding behavior under control of the --force option? That is to say,
> > only un-version the modified items when forced, just fail the folding by
> > default. If this is the preferred behavior, a --force option should be passed
> > to run_and_verify_update() function.
> >
> > And there is one more problem: should we output 'D ' on items that is
> > unversioned rather than deleted? When I first asked about folding a modified
> > item some days ago, Karl figured out that it should act like 'svn delete' --
> > leave the modified files in place. However, when I tried to see what does 'svn
> > delete' output in this situation, I found that it either refused to continue
> > or was forced to delete it. Any suggestion?
> 
> Oops.  Sorry -- I was really thinking of the behavior of 'svn up', not
> 'svn delete'.
> 
> That is, say you run 'svn up' from the top of a Greek Tree working copy
> (the usual test tree: iota, A, A/mu, A/D/..., etc).  In the repository,
> there's a change that removes the directory A/D/, and now you're going
> to receive that change.
> 
> But in your working copy, you've modified A/D/G/pi, and created an
> unversioned file at A/D/H/unversioned.txt.  When the update arrives, it
> will remove everything else, but it will leave the modified file and the
> unversioned file, and it will (of course) leave parent directories in
> place as necessary to reach those remaining items.
Emmm. I admit that I didn't considered this situation. It's very similar with
the situation here. So don't bother to interfere with the --force option since
we already chose not to do so in a similar situation.
> 
> That is the behavior I was proposing here: we should fold up all
> versioned and unmodified stuff, but leave behind anything unversioned or
> modified (and therefore leave the intermediate directories necessary to
> reach those items).
Yes, I got your idea even you didn't used a proper example. ;)

However, the difference between receiving deletion in repository and folding
local wc directory should still be taken into account. The flag 'D' is
traditionally used to represent deletion that is (or will) reflected in
repository. However, I currently expect a 'D ' output in the test cases even
if the deletion happens only in local wc when folding. This deserves a second
thought. Moreover, when making modified items unversioned rather than removed
in this test case, I still use the 'D' flag in expected_output. I doubt if it
is a proper way.  Do we need to introduce a new flag for this?

Rui, Guo

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

Re: [PATCH] depth test case: unversioned & modified items left untouched when folded

[Karl Fogel <kf...@red-bean.com>]

"Rui, Guo" <ti...@mail.ustc.edu.cn> writes:
> Hi,
>
> This will be my last test case for deselection interface of sparse-directory.
> I'll dig into update editor code, in which the functionality would most likely
> be implemented, in the next step.
>
> [[[
> Add test case to verify that folding a subtree will not destroy to content of
> unversioned & modified items.
>
> * subversion/tests/cmdline/depth_tests.py
>   (fold_tree_with_unversioned_modified_items): New tests.
>   (test_lists): Run it XFail
> ]]]

Committed in r30738.  I used "unversioned" instead of "added" to refer
to the new file, since "added" usually means "svn add" was run; I think
that's the only tweak I made.

> If we consider the unversioned & modified items as obstructions, should we
> make the folding behavior under control of the --force option? That is to say,
> only un-version the modified items when forced, just fail the folding by
> default. If this is the preferred behavior, a --force option should be passed
> to run_and_verify_update() function.
>
> And there is one more problem: should we output 'D ' on items that is
> unversioned rather than deleted? When I first asked about folding a modified
> item some days ago, Karl figured out that it should act like 'svn delete' --
> leave the modified files in place. However, when I tried to see what does 'svn
> delete' output in this situation, I found that it either refused to continue
> or was forced to delete it. Any suggestion?

Oops.  Sorry -- I was really thinking of the behavior of 'svn up', not
'svn delete'.

That is, say you run 'svn up' from the top of a Greek Tree working copy
(the usual test tree: iota, A, A/mu, A/D/..., etc).  In the repository,
there's a change that removes the directory A/D/, and now you're going
to receive that change.

But in your working copy, you've modified A/D/G/pi, and created an
unversioned file at A/D/H/unversioned.txt.  When the update arrives, it
will remove everything else, but it will leave the modified file and the
unversioned file, and it will (of course) leave parent directories in
place as necessary to reach those remaining items.

That is the behavior I was proposing here: we should fold up all
versioned and unmodified stuff, but leave behind anything unversioned or
modified (and therefore leave the intermediate directories necessary to
reach those items).

Does this help?

-Karl

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