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
Received on 2009-07-31 17:51:14 CEST