--keep-local and properties

[Neels Janosch Hofmeyr <ne...@elego.de>]

(Note, this is a different issue to the one pburba, Stefan Küng and me were
discussing in another thread)


Hi all,

I'd like confirmation from the community for a theoretical issue. It's
saturday, no replies on #svn-dev :)

$ svn delete ./dir --keep-local

This leaves the data in the file system after removing the items from
version control.

Another side effect is that svn no longer checks whether there are any local
modifications. The rationale is: we're going to keep everyting in the
filesystem anyway, so don't bother the user anymore.

Now, I have a problem with this: It only keeps *text* modifications on disk.
All *property* modifications are lost without a warning.

Properties may hold important data, I'm thinking e.g. of "svn:externals".

So, please tell me I'm right in following this path:
Upon `svn delete ./dir --keep-local':

(1) If there are only local text modifications, act as before. Remove from
version control, leave on disk.

(2) If there are local prop modifications, fail with an error similar to
when `--keep-local' were not supplied, but be specific about properties:
"svn: 'dir' has local property modifications -- commit or revert them first"

(3) Feature: add an option to `svn revert' that allows only reverting
property mods (doesn't exist yet AFAICT).


If I were to implement (2), I'd modify the signature of
svn_client__can_delete().

I'd like to even make it entirely private to that file. I can see only one
(local) caller of this function today, and libsvn_client/copy.c
(wc_to_wc_copy) used to use it as well until r21347.

Could this be used to publish client API to third-party elements? How do I
find out?
...would this thus become an svn_client__can_delete2()? Do we do that with
private API?

`make check' is successful if I rename this function and make it static and
private to libsvn_client/delete.c. So I'm tempted to go that way.

(If all above makes sense, that is.)

Thanks for any comments,
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359995

Re: --keep-local and properties

[Neels Janosch Hofmeyr <ne...@elego.de>]

Paul Burba wrote:
> On Sat, Jun 6, 2009 at 8:36 PM, Neels Janosch Hofmeyr<ne...@elego.de> wrote:
>> Mark Phippard wrote:
>>> Can you explain more why you think the command should fail?  The way I
>>> see it, there is little difference between svn delete with our without
>>> the --keep-local option.  In either case you are telling SVN to no
>>> longer version the item and are scheduling it for delete.  On the next
>>> commit the item will be deleted from the repository.  The only
>>> difference is that the file will be left in your working copy.  Other
>>> users that update will have the file removed from their working copy.
>>>
>>> If a file is unversioned it cannot have SVN properties.  So I do not
>>> see how that factors in, but perhaps you are thinking of something
>>> more subtle?  Such as what happens if you update when one of these
>>> files is schedule for delete and the update bring in changes?
>>>
>>> Mark
>> No, file contents are handled fine. My argument revolves around not wanting
>> to lose local mods to *properties*... (s.b.)
> 
> Hi Neels,
> 
> I understand the problem you are describing, though I wonder if this
> is something anyone is actually asking for.  That said, your first two

I'm specifically thinking of svn:externals, actually. An svn:externals prop
possibly holds information that is vital to some production release. When
the revision numbers are fixed, it could determine which revision is the
actual stable one etc., and it also determines the directory subtree loaded
into working copies (when externals are used).

If corporate users were to go about employing externals extensively, they
would be terrified by having their important working copy tree seen as not
important enough to keep safe.

Possibly, there are other props with similar implications?


> ideas for dealing with local prop changes and 'svn del --keep-local'
> seem sound:
> 
>> (1) If there are only local text modifications, act as before.
>> Remove from version control, leave on disk.
> 
>> (2) If there are local prop modifications, fail with an error
>> similar to when `--keep-local' were not supplied, but be specific
>> about properties: "svn: 'dir' has local property modifications --
>> commit or revert them first"

ok, cool.

> 
> Instead of (3) maybe make using --force in conjunction with
> --keep-local will work as --keep-local alone does today, i.e. text
> changes and directory structures intact, but prop changes (obviously)
> gone.

With text mods, --keep-local currently sort of implies --force. I also
remember some argument about not overloading --force too much with different
meanings. However, in this case, I guess it *does* make sense.

I'll make a test / issue / fix soon.

Thanks,
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360689

Re: --keep-local and properties

[Paul Burba <pt...@gmail.com>]

On Sat, Jun 6, 2009 at 8:36 PM, Neels Janosch Hofmeyr<ne...@elego.de> wrote:
> Mark Phippard wrote:
>> Can you explain more why you think the command should fail?  The way I
>> see it, there is little difference between svn delete with our without
>> the --keep-local option.  In either case you are telling SVN to no
>> longer version the item and are scheduling it for delete.  On the next
>> commit the item will be deleted from the repository.  The only
>> difference is that the file will be left in your working copy.  Other
>> users that update will have the file removed from their working copy.
>>
>> If a file is unversioned it cannot have SVN properties.  So I do not
>> see how that factors in, but perhaps you are thinking of something
>> more subtle?  Such as what happens if you update when one of these
>> files is schedule for delete and the update bring in changes?
>>
>> Mark
>
> No, file contents are handled fine. My argument revolves around not wanting
> to lose local mods to *properties*... (s.b.)

Hi Neels,

I understand the problem you are describing, though I wonder if this
is something anyone is actually asking for.  That said, your first two
ideas for dealing with local prop changes and 'svn del --keep-local'
seem sound:

> (1) If there are only local text modifications, act as before.
> Remove from version control, leave on disk.

> (2) If there are local prop modifications, fail with an error
> similar to when `--keep-local' were not supplied, but be specific
> about properties: "svn: 'dir' has local property modifications --
> commit or revert them first"

Instead of (3) maybe make using --force in conjunction with
--keep-local will work as --keep-local alone does today, i.e. text
changes and directory structures intact, but prop changes (obviously)
gone.

> (3) Feature: add an option to `svn revert' that allows only
> reverting property mods (doesn't exist yet AFAICT).

> Further limitation: only error out if there are non-mergeinfo changes -- but
> may mergeinfos in particular be important to catch sometimes?

I don't think we'd ever care about losing mergeinfo on a path we are
deleting, since the mergeinfo is describing merges to *that* path.  So
ignoring mergeinfo changes is safe IMO.  But is it really necessary to
special case this?  I'm under the impression that the overall use case
here is already quite rare, so this special case might be overkill.

Paul

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360642

Re: --keep-local and properties

[Neels Janosch Hofmeyr <ne...@elego.de>]

Mark Phippard wrote:
> Can you explain more why you think the command should fail?  The way I
> see it, there is little difference between svn delete with our without
> the --keep-local option.  In either case you are telling SVN to no
> longer version the item and are scheduling it for delete.  On the next
> commit the item will be deleted from the repository.  The only
> difference is that the file will be left in your working copy.  Other
> users that update will have the file removed from their working copy.
> 
> If a file is unversioned it cannot have SVN properties.  So I do not
> see how that factors in, but perhaps you are thinking of something
> more subtle?  Such as what happens if you update when one of these
> files is schedule for delete and the update bring in changes?
> 
> Mark

No, file contents are handled fine. My argument revolves around not wanting
to lose local mods to *properties*... (s.b.)

> 
> 
> On Sat, Jun 6, 2009 at 1:09 PM, Neels Janosch Hofmeyr<ne...@elego.de> wrote:
>> (Note, this is a different issue to the one pburba, Stefan Küng and me were
>> discussing in another thread)
>>
>>
>> Hi all,
>>
>> I'd like confirmation from the community for a theoretical issue. It's
>> saturday, no replies on #svn-dev :)
>>
>> $ svn delete ./dir --keep-local
>>
>> This leaves the data in the file system after removing the items from
>> version control.
>>
>> Another side effect is that svn no longer checks whether there are any local
>> modifications. The rationale is: we're going to keep everyting in the
>> filesystem anyway, so don't bother the user anymore.
>>
>> Now, I have a problem with this: It only keeps *text* modifications on disk.
>> All *property* modifications are lost without a warning.

...here, this ^^^ is my problem. If I have a file or dir, and I do some `svn
propset' locally, or a merge does them, for that matter (not talking about
mergeinfo, but about actual user supplied props).

If I then call `svn delete --keep-local', it will remove from version
control and keep the text file content and dir structure, but it will *not*
be able to keep the properties' values.

In other words, even though they are not file content changes, real changes
a user made are lost without a warning.

So the argument goes:

>>
>> Properties may hold important data, I'm thinking e.g. of "svn:externals".
>>
>> So, please tell me I'm right in following this path:
>> Upon `svn delete ./dir --keep-local':
>>
>> (1) If there are only local text modifications, act as before. Remove from
>> version control, leave on disk.
>>
>> (2) If there are local prop modifications, fail with an error similar to
>> when `--keep-local' were not supplied, but be specific about properties:
>> "svn: 'dir' has local property modifications -- commit or revert them first"

Further limitation: only error out if there are non-mergeinfo changes -- but
may mergeinfos in particular be important to catch sometimes?

>>
>> (3) Feature: add an option to `svn revert' that allows only reverting
>> property mods (doesn't exist yet AFAICT).
>>
>>
>> If I were to implement (2), I'd modify the signature of
>> svn_client__can_delete().
>>
>> I'd like to even make it entirely private to that file. I can see only one
>> (local) caller of this function today, and libsvn_client/copy.c
>> (wc_to_wc_copy) used to use it as well until r21347.
>>
>> Could this be used to publish client API to third-party elements? How do I
>> find out?
>> ...would this thus become an svn_client__can_delete2()? Do we do that with
>> private API?
>>
>> `make check' is successful if I rename this function and make it static and
>> private to libsvn_client/delete.c. So I'm tempted to go that way.
>>
>> (If all above makes sense, that is.)
>>
>> Thanks for any comments,
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360031

Re: --keep-local and properties

[Mark Phippard <ma...@gmail.com>]

Can you explain more why you think the command should fail?  The way I
see it, there is little difference between svn delete with our without
the --keep-local option.  In either case you are telling SVN to no
longer version the item and are scheduling it for delete.  On the next
commit the item will be deleted from the repository.  The only
difference is that the file will be left in your working copy.  Other
users that update will have the file removed from their working copy.

If a file is unversioned it cannot have SVN properties.  So I do not
see how that factors in, but perhaps you are thinking of something
more subtle?  Such as what happens if you update when one of these
files is schedule for delete and the update bring in changes?

Mark


On Sat, Jun 6, 2009 at 1:09 PM, Neels Janosch Hofmeyr<ne...@elego.de> wrote:
> (Note, this is a different issue to the one pburba, Stefan Küng and me were
> discussing in another thread)
>
>
> Hi all,
>
> I'd like confirmation from the community for a theoretical issue. It's
> saturday, no replies on #svn-dev :)
>
> $ svn delete ./dir --keep-local
>
> This leaves the data in the file system after removing the items from
> version control.
>
> Another side effect is that svn no longer checks whether there are any local
> modifications. The rationale is: we're going to keep everyting in the
> filesystem anyway, so don't bother the user anymore.
>
> Now, I have a problem with this: It only keeps *text* modifications on disk.
> All *property* modifications are lost without a warning.
>
> Properties may hold important data, I'm thinking e.g. of "svn:externals".
>
> So, please tell me I'm right in following this path:
> Upon `svn delete ./dir --keep-local':
>
> (1) If there are only local text modifications, act as before. Remove from
> version control, leave on disk.
>
> (2) If there are local prop modifications, fail with an error similar to
> when `--keep-local' were not supplied, but be specific about properties:
> "svn: 'dir' has local property modifications -- commit or revert them first"
>
> (3) Feature: add an option to `svn revert' that allows only reverting
> property mods (doesn't exist yet AFAICT).
>
>
> If I were to implement (2), I'd modify the signature of
> svn_client__can_delete().
>
> I'd like to even make it entirely private to that file. I can see only one
> (local) caller of this function today, and libsvn_client/copy.c
> (wc_to_wc_copy) used to use it as well until r21347.
>
> Could this be used to publish client API to third-party elements? How do I
> find out?
> ...would this thus become an svn_client__can_delete2()? Do we do that with
> private API?
>
> `make check' is successful if I rename this function and make it static and
> private to libsvn_client/delete.c. So I'm tempted to go that way.
>
> (If all above makes sense, that is.)
>
> Thanks for any comments,
> ~Neels
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359995



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360019