You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Ballard <ke...@sb.org> on 2004/09/29 08:31:44 UTC
[REQ] WC-only properties (local:)
I had an idea for a feature I'd love to see implemented but I haven't
had enough time to learn about the internals of SVN to implement it
myself.
A problem that crops up every now and then is I'd like to add a
property to a file but I don't want to commit it to the repo. For
instance, I may have scripts I wrote to facilitate my personal use of a
project that applies to nobody else. It doesn't make a lot of sense to
add it to the versioned svn:ignore property since it couldn't possibly
affect anybody else and that just clutters up the repo with information
that only applies to a single person. But it's also quite annoying to
have it show up every time I run an 'svn status'. And this applies to
other properties as well. For instance, a file may be set to
svn:eol-style=native but I personally want it set to svn:eol-style=CRLF
for some unknown reason. If I committed that to the repo, everybody
would get it as CRLF and that could be disastrous. But if I don't, I
have the wrong line endings on my end (don't ask me why I'd want CRLF,
this is hypothetical).
My solution? A separate prefix for unversioned WC-only properties,
properties that don't get committed to the repo. This would be
'local:'. And anything starting with 'local:svn:' could override the
respective 'svn:' property (although in the case of svn:ignore it might
want to append instead). That way I could add my own paths to
svn:ignore or override the svn:eol-style properties without affecting
the repository and without screwing anybody else up.
Any comments or suggestions?
--
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org
Re: [REQ] WC-only properties (local:)
Posted by Simon Large <sl...@blazepoint.co.uk>.
"Kevin Ballard" wrote
> A problem that crops up every now and then is I'd like to add a
> property to a file but I don't want to commit it to the repo. For
But having properties versioned and in the repo is a defining
characteristic. If you want to define client side behaviour on a per-user
basis you would not use properties.
> instance, I may have scripts I wrote to facilitate my personal use of a
> project that applies to nobody else. It doesn't make a lot of sense to
> add it to the versioned svn:ignore property since it couldn't possibly
> affect anybody else and that just clutters up the repo with information
> that only applies to a single person. But it's also quite annoying to
> have it show up every time I run an 'svn status'.
This particular problem can be solved with the global-ignores in the config
file, which is a per-user file on the client machine.
Simon
---------------------------------------------------------------------
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:)
Posted by 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:)
Posted by 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:)
Posted by 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:)
Posted by 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
Re: [REQ] WC-only properties (local:)
Posted by 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:)
Posted by Kevin Ballard <ke...@sb.org>.
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.
On Sep 29, 2004, at 12:45 PM, kfogel@collab.net wrote:
> You could just have the wrapper run 'svn st' and know how to ignore
> the things you want to ignore -- it would filter the st output. No
> properties required.
--
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org
Re: [REQ] WC-only properties (local:)
Posted by kf...@collab.net.
Kevin Ballard <ke...@sb.org> writes:
> What, you're telling me to make a wrapper that, on every use, adds the
> properties to the files, runs svn, then removes the properties from
> the files? That would be slow and *extremely* hackish and almost
> impossible to get working.
You could just have the wrapper run 'svn st' and know how to ignore
the things you want to ignore -- it would filter the st output. No
properties required.
---------------------------------------------------------------------
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:)
Posted by Archie Cobbs <ar...@dellroad.org>.
Kevin Ballard wrote:
> >>> So what you're asking for is purely client-side stuff... therefore
> >>> maybe
> >>> this could all be done in a wrapper script around the "svn" command.
> >
> > Well, it sounds like you're asking for 'svn' to implement what is
> > essentialy that exact same functionality, just within the 'svn'
> > binary itself instead of in a wrapper script... not sure that would
> > make it any less "hackish"...
>
> What you're asking me to do is write a wrapper that recurses into every
> directory tree rooted at the modified files/dirs and write to each
> affected property, do the action, then recurse back into every one and
> reverse that property modification. That's a lot of work and seems like
> it would extremely slow. What I'm asking is for a certain prefixed
> property to simply not be committed to the repo, as well as when using
> the special svn: properties to simply take a look at the relevant
> local:svn: property as well. It would be a lot more efficient and
> probably easier to do than what you're asking.
Yes, you are right about all that.. I'm just asking the underlying
question: where does "core" svn functionality stop and "custom"
client side functionality start? Not that my opinion counts for much,
but this feature seems like a good example of being on the "borderline".
I.e., it's a useful idea, but does it belong in the "stock" svn
binary? After all, there's nothing stopping somebody from writing
a "super-svn" binary based on "svn" that includes extra features
like this... it would be nice to see people doing creative stuff like
that, so we'd get some good "feature competition"...
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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:)
Posted by Kevin Ballard <ke...@sb.org>.
On Sep 29, 2004, at 11:14 AM, Archie Cobbs wrote:
> Kevin Ballard wrote:
>> What, you're telling me to make a wrapper that, on every use, adds the
>> properties to the files, runs svn, then removes the properties from
>> the
>> files? That would be slow and *extremely* hackish and almost
>> impossible
>> to get working.
>>
>>> So what you're asking for is purely client-side stuff... therefore
>>> maybe
>>> this could all be done in a wrapper script around the "svn" command.
>
> Well, it sounds like you're asking for 'svn' to implement what is
> essentialy that exact same functionality, just within the 'svn'
> binary itself instead of in a wrapper script... not sure that would
> make it any less "hackish"...
What you're asking me to do is write a wrapper that recurses into every
directory tree rooted at the modified files/dirs and write to each
affected property, do the action, then recurse back into every one and
reverse that property modification. That's a lot of work and seems like
it would extremely slow. What I'm asking is for a certain prefixed
property to simply not be committed to the repo, as well as when using
the special svn: properties to simply take a look at the relevant
local:svn: property as well. It would be a lot more efficient and
probably easier to do than what you're asking.
--
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org
Re: [REQ] WC-only properties (local:)
Posted by Archie Cobbs <ar...@dellroad.org>.
Kevin Ballard wrote:
> What, you're telling me to make a wrapper that, on every use, adds the
> properties to the files, runs svn, then removes the properties from the
> files? That would be slow and *extremely* hackish and almost impossible
> to get working.
>
> > So what you're asking for is purely client-side stuff... therefore maybe
> > this could all be done in a wrapper script around the "svn" command.
Well, it sounds like you're asking for 'svn' to implement what is
essentialy that exact same functionality, just within the 'svn'
binary itself instead of in a wrapper script... not sure that would
make it any less "hackish"...
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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:)
Posted by Kevin Ballard <ke...@sb.org>.
What, you're telling me to make a wrapper that, on every use, adds the
properties to the files, runs svn, then removes the properties from the
files? That would be slow and *extremely* hackish and almost impossible
to get working.
On Sep 29, 2004, at 10:47 AM, Archie Cobbs wrote:
> So what you're asking for is purely client-side stuff... therefore
> maybe
> this could all be done in a wrapper script around the "svn" command.
--
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org
Re: [REQ] WC-only properties (local:)
Posted by Archie Cobbs <ar...@dellroad.org>.
Kevin Ballard wrote:
> How would that solve anything? Now I have to merge everything from the
> trunk onto my branch, and everything from my branch onto the trunk.
>
> This isn't meant for properties that affect the code in the product,
> it's meant for stuff that affects my workflow. Stuff that a branch
> simply isn't meant for.
>
> > I'll ask the obvious question: why not just create your own branch
> > and add your properties there?
So what you're asking for is purely client-side stuff... therefore maybe
this could all be done in a wrapper script around the "svn" command.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
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:)
Posted by Kevin Ballard <ke...@sb.org>.
How would that solve anything? Now I have to merge everything from the
trunk onto my branch, and everything from my branch onto the trunk.
This isn't meant for properties that affect the code in the product,
it's meant for stuff that affects my workflow. Stuff that a branch
simply isn't meant for.
On Sep 29, 2004, at 10:18 AM, Archie Cobbs wrote:
> I'll ask the obvious question: why not just create your own branch
> and add your properties there?
--
Kevin Ballard
kevin@sb.org
http://www.tildesoft.com
http://kevin.sb.org
Re: [REQ] WC-only properties (local:)
Posted by Archie Cobbs <ar...@dellroad.org>.
Kevin Ballard wrote:
> A problem that crops up every now and then is I'd like to add a
> property to a file but I don't want to commit it to the repo. For
> instance, I may have scripts I wrote to facilitate my personal use of a
> project that applies to nobody else. It doesn't make a lot of sense to
> add it to the versioned svn:ignore property since it couldn't possibly
> affect anybody else and that just clutters up the repo with information
> that only applies to a single person. But it's also quite annoying to
> have it show up every time I run an 'svn status'. And this applies to
> other properties as well. For instance, a file may be set to
> svn:eol-style=native but I personally want it set to svn:eol-style=CRLF
> for some unknown reason. If I committed that to the repo, everybody
> would get it as CRLF and that could be disastrous. But if I don't, I
> have the wrong line endings on my end (don't ask me why I'd want CRLF,
> this is hypothetical).
I'll ask the obvious question: why not just create your own branch
and add your properties there?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org