[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: bring on your concerns about svn:hold, please

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 23 Aug 2011 09:43:09 -0400

On Tue, Aug 23, 2011 at 4:32 AM, Julian Foad <julian.foad_at_wandisco.com>wrote:

> Mark Phippard wrote:
> > [...] You like to talk about the IDE use case, so let's talk about
> > it. That is where I am coming from on this too. In Subclipse, [...]
> Mark (or anyone), do you recognize the use case described by Clemens
> Anhuth in <http://subversion.tigris.org/issues/show_bug.cgi?id=3028>?
> Use case (2) - Eclipse folder, from issue #3028
> "For example we have a complete Eclipse instance in our svn
> repository and we want to ignore every change in its directory
> and below. Because Eclipse more or less at random creates and
> deletes file from its own directory we have no way of knowing
> which individual files may be change or deleted by starting
> Eclipse. To avoid that an update creates files again that were
> deleted by running Eclipse the ignore setting I am asking for
> should also apply to updates. [...]"
> Is this use case important? Can such a case be adequately handled in
> practice by what we've been discussing, despite what Clemens claims
> about the need for recursive effect and avoiding the re-creation of
> deleted files?
I have never heard anyone ask for this, so while I think it is probably a
valid use case, I cannot imagine it is common enough to be important. I
also have to imagine in most cases like this the Eclipse IDE files would be
stored in the tree in such a way that it was relatively easy to simply
commit from another part of the tree to ignore it.

In terms of how we could handle the use-case, we would have to allow
svn:hold to be set on folders and then have that mean that commit does not
harvest-committables from children of that folder. Do I think we should do
this ... probably not.

Mark Phippard
Received on 2011-08-23 15:43:41 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.