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

Re: again: overwriting resource -> deleted and not modified

From: Mark Phippard <markp_at_softlanding.com>
Date: 2005-11-26 20:09:32 CET

Marc Sherman <msherman@projectile.ca> wrote on 11/26/2005 12:52:05 PM:

> Mark Phippard wrote:
> >> If this feature hasn't been released yet, can I recommend that you
> >> it as "subclipse:DeferFileDelete"
> >
> > Why?
> Well, for the same reasons you would scope any name in an uncontrolled
> global namespace; to avoid name clashes with other users of the
> namespace. What if I've already got files with that property defined,
> with different semantics?
> > Ultimately it comes back to that I just do not see any point in adding
> > scoping to a name a like this.
> You don't ship Subclipse's packages in the default java namespace. The
> same reasons apply to why you should scope any svn properties you define
> with unique semantics.

I understand the argument and analogy, I just do not think it is correct.
In the case of our Java code, we want the namespace to be private for
obvious reasons. In the case of this property, I want it to be public.
Let's say that someone developing an integration for Visual Studio, or
IntelliJ or Netbeans has a need for a similar feature. I would want them
to use the same property name if possible. If we put subclipse: in the
name, they won't. We support a lot of the tsvn: properties in Subclipse
and I really wish they had been named something else. But, tsvn is not
that objectionable. If the properties had been named tortoisesvn:xxx then
I probably would not have supported the same properties.

I like the idea of using a namespace when there are a number of properties
that are related. For example, I wrote the initial specifications for the
bug tracking integration supported by TortoiseSVN and Subclipse. In that
case, since there were several properties that controlled the integration
it made sense to invent a namespace so that they were grouped together.

How about using a generic/concept namespace for this? Something like one
of these:


The first one would probably be OK, but I still think that
"DeferFileDelete" might be best. If someone did have that property
defined with a value of true, it seems unlikely it would be for some other
reason. Also, having the property set isn't the end of the world. It
just means that files you delete will have a status of missing until you
commit them from the commit dialog.


Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Sun Nov 27 06:09:32 2005

This is an archived mail posted to the Subclipse Users mailing list.

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