Christopher Clarke wrote:
> I've been discussing this on the user's list (tying to go through proper
> channels before bug tracker)
Thank you. And thanks to Stefan for pointing to the archived thread:
<http://svn.haxx.se/users/archive-2009-07/0394.shtml>.
Now I've written a long reply, but I can sum it up in a few sentences. I
think you have a valid request for adding support for a particular way
of using Subversion. I think you underestimate how hard it is for most
readers to see why you think you need a new feature, and exactly what
its purpose is (never mind yet its design and user interface).
If you are interested in making this happen, would you be able to
participate in designing it? I don't mean designing C functions, just
the high-level concept and what it needs to do and how it fits in with
Subversion's existing features. There really is no substitute for
discussing a feature with a potential user of it.
> and the discussion has centered on the
> reasons why I want the feature, not on whether it's reasonable and
> feasible to include it in Subversion, so I'm asking here.
It's probably feasible, but whether it is reasonable depends completely
on whether there are use cases that fall within reasonable use of
Subversion and don't have a satisfactory alternative. Most people here
have never had that need and have only heard it requested two or three
times in the many years of Subversion's life, and in those cases I seem
to recall (but have not verified) that the people asking decided that an
alternative solution was reasonable for them.
That's why the discussion has rightly focussed on why you need it. It's
not the precise details of your situation that matter, but in what
fundamental way your situation differs from those supported by
Subversion's current concepts of operation.
So...
> I would like a way to start ignoring a file that has been added to the
> repository for all users without deleting it from their local working
> copies. You can assume that 1) I have a good reason to do this and 2) I
> cannot execute commands on the users' local machines other than standard
> svn commands.
We can assume that you have a good reason to achieve the end result
you're looking for, but we cannot assume that you need Subversion to
"start ignoring a file that has been added ..." in order to achieve your
goal. You need to articulate and discuss what that means and the reasons
why it is necessary.
After reading the discussion thread linked above, I see that you have
discussed some of the issues and I think I understand your position.
This is the way I would describe it, trying to highlight the differences
from standard usage.
You use Subversion to version selected files within a long-lived local
tree that also contains unversioned files. Such a tree is a Subversion
Working Copy but the unversioned files in it are important local data,
neither disposable nor intended to be versioned.
Subversion currently supports deleting a file with the following
concept:
You have a file 'X' in your WC, corresponding to file 'X' in the
repository.
You ask Subversion to delete 'X', and commit.
Subversion deletes 'X' from your WC.
Subversion deletes 'X' in the repository.
User B has a file named 'X' in his WC.
User B requests an update.
Subversion deletes 'X' from his WC.
And adding a file is a complementatry part of the same concept:
You have no 'X' in your WC, nor in the repository.
You create a file 'X' in your WC.
You add 'X' to Subversion's control.
You commit.
Subversion creates a file 'X' in the repository.
User B has no 'X' in his WC.
User B requests an update.
Subversion creates a file 'X' in his WC.
But the concept you want is to convert a file from versioned to
unversioned (but existing). You have some versioned files (or
directories) and instead of the above concept of "delete" you wish to
commit a change that makes them become unversioned but does not delete
the working copies of them from all the users' WCs.
In my mind there also needs to be a complementary "adding" part of the
concept, in which we instruct Subversion to "make file X become
versioned, without trying to add it to other WCs when updating them".
Together, those two parts would make a concept. (Whether it's a
reasonable concept to support is still for discussion.)
> It doesn't matter to me how svn handles the item once it's been "force
> ignored." When users switch between revisions, it is ok for the item to
> switch between a versioned and non-versioned state. It's also ok for svn
> to forget that the item was ever added to the repository.
OK. The design does need to address questions like that. It also needs
to address where (in terms of which logical items in which revision(s))
the behaviour flag is to be stored, when it shall be set (by client or
by server, during what commands), when it shall be noticed (by client or
by server, during what commands), and what it shall mean.
One thing not yet clear is whether in your case the content of the item
to be deleted is likely to be the same as in the repository.
> You could also think of this feature as "undo add" or "unadd".
>
> Some possible solutions I've thought of:
Heh, not meaning to be rude but it's a bit of a stretch to call these
"solutions" :-) If you've thought about them more deeply, it would be
good to share the thoughts.
> - add an unadd command
... that perhaps would behave like "svn delete --keep-local" except that
it would also record metadata in the repository as part of the revision
in which the deletion occurs, saying "targets X [, Y, ...] should become
unversioned rather than be deleted". During any update to this revision
from a revision in which any of the mentioned targets existed, they
shall be made unversioned, regardless whether their content currently
matches the repository content.
> - globally apply --keep-local flag of svn delete
You mean: change "svn delete --keep-local" to work as for "svn unadd"
above?
> - change the behavior of the svn:ignore property to ignore the item(s)
> no matter what
A bit vague. But we can't change the semantics of "svn:ignore" in a
backwards-incompatible way now.
> - add a new property (svn:force-ignore? svn:keep-local?)
Add it to what nodes in what revision(s), when? What would it mean? What
would the client do with it?
> Not on the list, so please reply all.
That's no problem.
I hope all that helps to explain why it's not the obvious simple feature
addition that it may sound like at first. Consider this a hint at how to
proceed. I can't promise to have more involvement than this but I look
forward to hearing more.
Regards,
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372484
Received on 2009-07-20 02:27:55 CEST