You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christopher Clarke <ti...@fuscata.com> on 2009/07/16 16:58:01 UTC
Force ignore for all peers
Hello,
I've been discussing this on the user's list (tying to go through proper
channels before bug tracker) 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.
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.
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.
You could also think of this feature as "undo add" or "unadd".
Some possible solutions I've thought of:
- add an unadd command
- globally apply --keep-local flag of svn delete
- change the behavior of the svn:ignore property to ignore the item(s)
no matter what
- add a new property (svn:force-ignore? svn:keep-local?)
Not on the list, so please reply all.
Thanks,
Chris
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2371816
Re: Force ignore for all peers
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jul 16, 2009 at 12:58:01PM -0400, Christopher Clarke wrote:
> Hello,
>
> I've been discussing this on the user's list (tying to go through proper
> channels before bug tracker) 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.
For people not on users@, the old thread is here:
http://svn.haxx.se/users/archive-2009-07/0394.shtml
Stefan
Re: Force ignore for all peers
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2009-07-28, Christopher Clarke wrote:
> On 07/19/2009 08:27 PM, Julian Foad wrote:
> > 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.)
>
> I see your point, but I wonder if we it makes more sense to think about
> this feature like a global forced ignore. Currently you can ignore and
> un-ignore something in your working copy (as long as it's not been added
> to version control) and the ignored state is stored in the repository
> and applied to all working copies. I would like the ability to ignore
> something no matter if it's in the repository or under local version
> control or modified or any combination/none of the above. You'd be able
> to change the ignored state at any point.
Maybe it's just me but that sounds a bit vague. How about you spell out
exactly what you mean, in terms of semantics (when does the "ignore"
take effect, what happens in each possible case) and we'll then be able
to consider it more clearly.
> >> 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.
>
> Not sure why this matters... The content may be the same, may be different.
It matters because if it's the same, Subversion can reasonably assume
that it's "safe" to quietly ignore or delete it because no data will be
lost from the system. In current Subversion, if your local copy of the
file is different, Subversion will not just delete it but notify you
that there's a problem (svn "skips" it), and so I would expect a
now-start-ignoring-it design to do something too.
[...]
> Let me try to give a real-life use case:
>
> We have a web-based app that incorporates 3rd party FOSS apps. Normally
> these apps would not be in the repository. They are physically stored
> under the project directory, but ignored. (This is for a number of
> reasons, that I can explain if needed.)
That's a familiar scenario: we do this (optionally) in a Subversion
source tree with Subversion's 3rd-party dependencies 'apr' and
'apr-util' being ignored top-level directories, that will be built by
the build script if present but are ignored in terms of version control.
> Now, say one of the 3rd-party
> apps is ModuleX, which has it's own auto-update feature. What happens
> when we need to hack ModuleX? (Sucky, but it happens.) We: 1) submit a
> bug report/feature request to CompanyX the maker of ModuleX, 2) add
> ModuleX to the repository (un-ignore and commit) and 3) make our changes
> to ModuleX and commit them. Say we're now at rev 111. After some time,
> CompanyX makes the changes we wanted.
OK, I can imagine this.
> So we want to start ignoring
> ModuleX again. Say we're now at rev 123.
Here's where I think our views differ: I wouldn't expect to "start
ignoring". I would say "OK, we no longer want a copy of this code in our
versioned project tree, we want to delete it from there, and make
Subversion ignore anything that might appear at that path on disk so
that when we install a copy of the 3rd-party software from its official
download site to this directory, "svn status" won't print a question
mark.
> If someone reverts his working copy to rev 119, he should have the
> versioned, hacked copy of ModuleX. If he then moves back to HEAD, his
> copy of ModuleX should be ignored and unchanged.
If I hear you right, you want to leave on disk a copy of that tree that
came out of your repository, but the revision of it that you want to
leave there is... whatever revision of it the user last updated to,
while it was still active in your repository.
Usually, in Subversion, updating from rX to rZ is the same as updating
from rX to rY and then from rY to rZ. But this would make it different.
Not that that's necessarily a show-stopper, just pointing out it's a big
departure.
> He will have to make
> sure the auto-update feature is working, but that's his problem. For our
> company at least, the *much* more common task is to move forward and I
> want to make sure that if someone does nothing but the standard
> update-work-commit cycle, he's not going to muck up the repository. As
> it works now, if someone updates to 123 (at which point ModuleX
> auto-updates)
You've lost me there. Was the ModuleX sub-tree deleted from the
repository in rev 123? If so, ModuleX will get deleted from disk. So I
guess you didn't mean that. Not sure what "auto-updates" means.
> and he then commits, he will commit ModuleX to the
> repository. There's no way to get it out and keep it out.
Sorry, can you explain what change Subversion would commit and why.
> The current possible solutions to this problem are: 1) change the
> program in some way (perhaps multiple possible locations for ModuleX) or
> 2) have everyone manually remove ModuleX from version control using the
> following process: warn + educate, delete, commit, everyone export
> local, everyone rename, everyone update.
>
> #1 doesn't work for me because it takes time to implement, increases
> possible bugs, and increases execution time and resources required by my
> app. #2 doesn't work for me because it takes a lot time, is annoying to
> many people on the team, the likelihood of errors is high, and some
> peers are machines not people (which increases downtime and possible
> errors).
>
> Thanks for your time... Perhaps someone has a solution to this use case
> that I haven't thought of?
Likely, but I'm still not quite on the same page as you.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377463
Re: Force ignore for all peers
Posted by Christopher Clarke <ti...@fuscata.com>.
On 07/19/2009 08:27 PM, Julian Foad wrote:
> 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.
Absolutely. Despite offering "solutions" ("directions" or "paths" would
have been better perhaps), I was merely trying to explain the problem as
clearly as possible.
> ...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.
Fair enough.
>> 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.)
I see your point, but I wonder if we it makes more sense to think about
this feature like a global forced ignore. Currently you can ignore and
un-ignore something in your working copy (as long as it's not been added
to version control) and the ignored state is stored in the repository
and applied to all working copies. I would like the ability to ignore
something no matter if it's in the repository or under local version
control or modified or any combination/none of the above. You'd be able
to change the ignored state at any point.
>> 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.
Not sure why this matters... The content may be the same, may be different.
>> 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.
Ok, "directions"...
>> - 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.
Yes, exactly.
>> - globally apply --keep-local flag of svn delete
>
> You mean: change "svn delete --keep-local" to work as for "svn unadd"
> above?
Yes.
>> - 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.
Understood, almost didn't say it, but as I said, I was trying to explain
the problem.
>> - 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?
Same as the above.
> 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.
Yes, again, understood...
Let me try to give a real-life use case:
We have a web-based app that incorporates 3rd party FOSS apps. Normally
these apps would not be in the repository. They are physically stored
under the project directory, but ignored. (This is for a number of
reasons, that I can explain if needed.) Now, say one of the 3rd-party
apps is ModuleX, which has it's own auto-update feature. What happens
when we need to hack ModuleX? (Sucky, but it happens.) We: 1) submit a
bug report/feature request to CompanyX the maker of ModuleX, 2) add
ModuleX to the repository (un-ignore and commit) and 3) make our changes
to ModuleX and commit them. Say we're now at rev 111. After some time,
CompanyX makes the changes we wanted. So we want to start ignoring
ModuleX again. Say we're now at rev 123.
If someone reverts his working copy to rev 119, he should have the
versioned, hacked copy of ModuleX. If he then moves back to HEAD, his
copy of ModuleX should be ignored and unchanged. He will have to make
sure the auto-update feature is working, but that's his problem. For our
company at least, the *much* more common task is to move forward and I
want to make sure that if someone does nothing but the standard
update-work-commit cycle, he's not going to muck up the repository. As
it works now, if someone updates to 123 (at which point ModuleX
auto-updates) and he then commits, he will commit ModuleX to the
repository. There's no way to get it out and keep it out.
The current possible solutions to this problem are: 1) change the
program in some way (perhaps multiple possible locations for ModuleX) or
2) have everyone manually remove ModuleX from version control using the
following process: warn + educate, delete, commit, everyone export
local, everyone rename, everyone update.
#1 doesn't work for me because it takes time to implement, increases
possible bugs, and increases execution time and resources required by my
app. #2 doesn't work for me because it takes a lot time, is annoying to
many people on the team, the likelihood of errors is high, and some
peers are machines not people (which increases downtime and possible
errors).
Thanks for your time... Perhaps someone has a solution to this use case
that I haven't thought of?
Cheers,
-Chris
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2376333
Re: Force ignore for all peers
Posted by Julian Foad <ju...@btopenworld.com>.
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