Re: [REQ] WC-only properties (local:)

[Julian Foad <ju...@btopenworld.com>]

Kevin Ballard wrote:
> D'oh, wrong button!
> 
> Anyway, svn:ignore is used for other things too, like adding new files 
> and stuff.
> 
> And this local: idea can be used for other properties too, like 
> svn:eol-style and things like that. Or if I have a script that uses 
> properties of the file and a given property makes sense to be different 
> from user to user (or just needs to be overridden by a few specific 
> users) local: properties could be used there too.

Kevin, you may have a good idea for a useful enhancement.  I suspect that the reasons you are not getting much positive feedback are:

+ other people don't seem to have found much of a need for this yet;

+ you didn't seem to give a concrete example of something being made much easier by your new properties (the example above about some script is not detailed enough for us to see the usefulness of it);

+ the suggestion immediately looks like it has many open questions and awkward interactions (e.g., do these new properties get copied by "svn copy"? reported by "svn diff" as themselves and/or as the properties that they shadow?).

Your concrete example was adding personal files to "svn:ignore" but without it being a scheduled change that shows up in "svn status".  I have wanted this, and I found the (clumsy, non-ideal) work-around of specifying it in global-ignores in the config file instead.  I have never encountered another need for these local property overrides.  You hypothesise about wanting to override svn:eol-style, but a hypothetical use case is not a convincing argument.

Given that other people have not spoken up and thought through the semantics and interactions and consequences of such a feature, perhaps you would like to do so, and say exactly how it would work, at least for some concrete examples and in some edge cases.  If you can conclude with "Yes, it _can_ all fit together logically, and this is how it would work, and this is why it would be useful," then you will find that people will be more willing to discuss it.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: [REQ] WC-only properties (local:)

[Arild Fines <ar...@broadpark.no>]

Julian Foad wrote:
> Kevin Ballard wrote:
>> D'oh, wrong button!
>>
>> Anyway, svn:ignore is used for other things too, like adding new
>> files and stuff.
>>
>> And this local: idea can be used for other properties too, like
>> svn:eol-style and things like that. Or if I have a script that uses
>> properties of the file and a given property makes sense to be
>> different from user to user (or just needs to be overridden by a few
>> specific users) local: properties could be used there too.
>
> Kevin, you may have a good idea for a useful enhancement.  I suspect
> that the reasons you are not getting much positive feedback are:
>
> + other people don't seem to have found much of a need for this yet;

Ankh could actually benefit from local-only properties. Ankh lets the user
decide if he wants Ankh to load for a specific solution. To persist this
choice, we currently create a file in the solution directory, which is
checked upon solution load.

With local properties, we could instead create a local:ankh.load(or
local:ankh:load) property on the solution file and check that when a
solution is loaded. I could also imagine other project/solution specific
settings we might want to store using such a mechanism. I'd rather avoid
littering the project directories with files created by Ankh, especially
when there's already a metadata storage facility available.

I am sure there are also other similar scenarios in which SVN tools could
store working copy-specific metadata using these properties.

--
Arild

AnkhSVN: http://ankhsvn.tigris.org
Blog: http://ankhsvn.com/blog
IRC: irc://irc.freenode.net/ankhsvn

"Gentlemen, you can't fight in here! This is the war room!"


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [REQ] WC-only properties (local:)

[Branko Čibej <br...@xbc.nu>]

Greg Hudson wrote:

>Although I imagine seversal classes of users would find a use for this
>feature, I think it would make libsvn_wc even more hackish than it
>already is, and would generally complicate Subversion more than it's
>worth.
>
>But maybe there's a more general and more elegant solution.  I'll
>observe that people may want to have local changes to file contents, as
>well as properties, without having them committed.  So maybe what we
>want is some kind of "commit mask" which you can drop into a working
>copy (not sure how--a specially named file, a file in .svn, a directory
>property) to prevent specific changes from being committed.  Then only
>the commit subsystem needs to be affected, not the entirety of
>libsvn_wc.
>  
>
This whole thread seems to be moving towards reinventing two-stage 
commits, where changes (and commits) stay local by default until 
explicitly promoted to the (a) repository. Svk does something like that, 
I believe (and so do BitKeeper and AccuRev, for example). I'm fairly 
sure this is an option we'd want to have in 2.0, along wit the famous 
libsvn_wc rewrite; in fact I envision stealing the design from svk, if 
possible.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [REQ] WC-only properties (local:)

[Greg Hudson <gh...@MIT.EDU>]

Although I imagine seversal classes of users would find a use for this
feature, I think it would make libsvn_wc even more hackish than it
already is, and would generally complicate Subversion more than it's
worth.

But maybe there's a more general and more elegant solution.  I'll
observe that people may want to have local changes to file contents, as
well as properties, without having them committed.  So maybe what we
want is some kind of "commit mask" which you can drop into a working
copy (not sure how--a specially named file, a file in .svn, a directory
property) to prevent specific changes from being committed.  Then only
the commit subsystem needs to be affected, not the entirety of
libsvn_wc.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [REQ] WC-only properties (local:)

[Kevin Ballard <ke...@sb.org>]

On Oct 3, 2004, at 5:07 PM, Julian Foad wrote:

> + you didn't seem to give a concrete example of something being made 
> much easier by your new properties (the example above about some 
> script is not detailed enough for us to see the usefulness of it);

Here's another example. I have a Makefile for an Xcode project in a 
repository. The Makefile is so I can svn update and build and install 
changes without having to open up Xcode. Anyway, it assumes 2 things: 
that your built products are put in the build directory instead of 
somewhere else, and that you want the built application to be installed 
in ~/Applications. It would be nice to be able to use local: properties 
to specify build products and final location if different from the 
assumptions. Currently anybody who needs this has to modify the 
Makefile and then avoid committing it to the repository on any future 
commits. Having local: properties would be very handy here.

> + the suggestion immediately looks like it has many open questions and 
> awkward interactions (e.g., do these new properties get copied by "svn 
> copy"? reported by "svn diff" as themselves and/or as the properties 
> that they shadow?).

What I was thinking was they'd act just like regular properties except 
they don't live in the repo, so svn copy would copy them, etc. svn diff 
wouldn't report them since there's nothing to diff against.

Your comment about shadowing makes me thing I wasn't clear about 
something. A local:svn:ignore property doesn't shadow svn:ignore per 
se, since in this case you'd probably want it to be added to the ignore 
list and not replacing the ignore list (although, say, 
local:svn:eol-style would replace svn:eol-style). Shadowing like that 
would imply any time you read svn:ignore it would check 
local:svn:ignore and use that instead, and that would imply you could 
never get the real value of svn:ignore without removing your 
local:svn:ignore property. What I'm thinking is any code that uses 
svn:ignore (and the other special properties) would check 
local:svn:ignore (or the respective local: property) as well. That way 
svn propget could still show the original value for svn:ignore yet 
anything that uses it would use the local property too.

-- 
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org