You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by TBrowder <tb...@cox.net> on 2004/03/18 12:44:36 UTC
Re: Proposed New Features (FINAL)
I guess I'll have to do it all through perl scripts.
Gentlemen, it's been a learning experience. You have a great product
and I wish you well (and I will use it). But I think I understand
better how xemacs came to be.
Tom Browder
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Features (FINAL)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 19, 2004 at 11:50:03PM +0100, Arild Fines wrote:
> Max Bowsher wrote:
> > Arild Fines wrote:
>...
> >> Is it? A .svnignore file wouldn't have to be versioned, meaning that
> >> different developers can have different ignore patterns set. Very useful if
> >> the developers are using different build environments.
> >
> > Why not just add all the relevant ignore patterns to the repository?
>
> But why should you be forced to version something that's essentially
> private? As long as svn:ignore has to be maintained server side, it is *not*
> a duplicate of the .svnignore proposal.
Well, we *do* have the "global-ignores" config option. That isn't specific
to a working copy, but it probably fits the bill.
> However, if SVN was to support the idea of a working-copy-only/nonversioned
> property(a --wc-prop flag to svn ps|pe, perhaps?), it would be a different
> matter. This could be useful in other situations as well - various
> Subversion clients could use it for maintaining working copy-specific
> metadata. I can think of at least one scenario where Ankh could find use for
> this.
>
> Was such a feature ever considered?
Nope. Precedent is to have a single union of all the types and put those
into the svn:ignore property. That concept seems to have worked quite well
for CVS (same model, different expression, though), so we didn't see a
need to go back for a rethink/redesign that may have resulted in your
alternative.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Features (FINAL)
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 19-03-2004 22:31, Max Bowsher wrote:
>Arild Fines wrote:
> > Max Bowsher wrote:
> >> 2) .svnignore
> >>
> >> Essentially a duplicate of the svn:ignore property.
> >
> > Is it? A .svnignore file wouldn't have to be versioned, meaning that
> > different developers can have different ignore patterns set. Very useful
>if
> > the developers are using different build environments.
>
>Why not just add all the relevant ignore patterns to the repository?
1) Because its a pain to maintain across lots of dirs (no inheritance or
search rules right?)
2) Isn't this done well enough with global-ignores in [miscellany] in the
config file?
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Proposed New Features (FINAL)
Posted by Arild Fines <ar...@broadpark.no>.
Max Bowsher wrote:
> Arild Fines wrote:
>> Max Bowsher wrote:
>>> 2) .svnignore
>>>
>>> Essentially a duplicate of the svn:ignore property.
>>
>> Is it? A .svnignore file wouldn't have to be versioned, meaning that
>> different developers can have different ignore patterns set. Very useful
if
>> the developers are using different build environments.
>
> Why not just add all the relevant ignore patterns to the repository?
But why should you be forced to version something that's essentially
private? As long as svn:ignore has to be maintained server side, it is *not*
a duplicate of the .svnignore proposal.
However, if SVN was to support the idea of a working-copy-only/nonversioned
property(a --wc-prop flag to svn ps|pe, perhaps?), it would be a different
matter. This could be useful in other situations as well - various
Subversion clients could use it for maintaining working copy-specific
metadata. I can think of at least one scenario where Ankh could find use for
this.
Was such a feature ever considered?
--
Arild
AnkhSVN: http://ankhsvn.tigris.org
Blog: http://ankhsvn.com/blog
IRC: irc://irc.freenode.net/ankhsvn
"We've got to find out what people want from fire, how they relate to it,
what sort of image it has for them.' The crowd were tense. They were
expecting something wonderful from Ford.`Stick it up your nose,' he
said.`Which is precisely the sort of thing we need to know,' insisted the
girl, `Do people want fire that can be fitted nasally?'"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Features (FINAL)
Posted by Max Bowsher <ma...@ukf.net>.
Arild Fines wrote:
> Max Bowsher wrote:
>> 2) .svnignore
>>
>> Essentially a duplicate of the svn:ignore property.
>
> Is it? A .svnignore file wouldn't have to be versioned, meaning that
> different developers can have different ignore patterns set. Very useful
if
> the developers are using different build environments.
Why not just add all the relevant ignore patterns to the repository?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Proposed New Features (FINAL)
Posted by Arild Fines <ar...@broadpark.no>.
Max Bowsher wrote:
> 2) .svnignore
>
> Essentially a duplicate of the svn:ignore property.
Is it? A .svnignore file wouldn't have to be versioned, meaning that
different developers can have different ignore patterns set. Very useful if
the developers are using different build environments.
--
Arild
AnkhSVN: http://ankhsvn.tigris.org
Blog: http://ankhsvn.com/blog
IRC: irc://irc.freenode.net/ankhsvn
"We've got to find out what people want from fire, how they relate to it,
what sort of image it has for them.' The crowd were tense. They were
expecting something wonderful from Ford.`Stick it up your nose,' he
said.`Which is precisely the sort of thing we need to know,' insisted the
girl, `Do people want fire that can be fitted nasally?'"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Features (FINAL)
Posted by Max Bowsher <ma...@ukf.net>.
TBrowder wrote:
> I guess I'll have to do it all through perl scripts.
>
> Gentlemen, it's been a learning experience. You have a great product
> and I wish you well (and I will use it). But I think I understand
> better how xemacs came to be.
>
> Tom Browder
I think you have misunderstood the strong desire of the subversion community
to ensure that features are well designed from the start, as unhelpfulness.
Let me summarize the status of your proposals, as I see it:
1) SVNROOT
People, including me, don't really understand why you want this embedded in
subversion, rather than simply using shell variables.
2) .svnignore
Essentially a duplicate of the svn:ignore property. I assume you made the
proposal because you hadn't discovered that feature, and withdrew it when
you did.
3) Revision tags
People are concerned about the confusion having 2 types of tags could cause.
There were some suggestions about improving svn log, and organizing your
tags directory, but you didn't comment on these, unless I missed it.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Features (FINAL)
Posted by McClain Looney <m...@loonsoft.com>.
such egregious slander has no place on a list such as this.
On Mar 18, 2004, at 6:44 AM, TBrowder wrote:
> But I think I understand
> better how xemacs came to be.
---
McClain Looney
m@loonsoft.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Features (FINAL)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-03-18 at 07:44, TBrowder wrote:
> Gentlemen, it's been a learning experience. You have a great product
> and I wish you well (and I will use it). But I think I understand
> better how xemacs came to be.
It certainly didn't happen because someone showed up, proposed a few
features, and was "too old" to argue for them when people gave reasons
why they shouldn't be supported. People don't fork projects that
lightly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org