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.
>> 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
> You have a file 'X' in your WC, corresponding to file 'X' in the
> 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.
>> - 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"
>> - 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
>> - 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
Thanks for your time... Perhaps someone has a solution to this use case
that I haven't thought of?
Received on 2009-07-28 20:53:57 CEST