You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Trampas Stern <ts...@dacaudio.com> on 2002/08/30 18:24:35 UTC
Searching Properties
Hello all,
I was wondering if it was possible to search the properties meta data
using subversion? Like find all files/folders which has property 'color'
set to green.
Thanks
Trampas
Re: svn add ignoring versioned files (was: Re: Searching Properties)
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hello.
On Tue 2002-09-03 at 13:40:25 -0500, Karl Fogel wrote:
> Colin D Bennett <cb...@radsoft.com> writes:
> > Does anyone see a problem with simply ignoring files, even if explicitly
> > specified (as with "svn add -R *" or "svn add *")? I wouldn't mind svn
> > silently ignoring already-added files.
>
> So we simply declare 'svn add' to be idempotent (I love that word).
>
> Sure, I see no problem with that. Anyone else?
Just my 2 cents...
I started writing about how I do not like the idea about svn not
telling me if I messed up, even in a harmless way (specifying a file
which is already checked in).
The main reason being that, AFAIK, svn has no way to tell that I used
a joker. I could have typed all files/dirs by hand on the command
line. And if I type "svn add foobar" explicitly for a foobar which is
already added, I have messed up in some way (well, at least I think
so).
In the course of trying to provide further arguments I noticed that
whether one would consider a explicit message the expected behaviour
or not, depends on what action "svn add" means:
- if it means "add this file/dir to the repository" (what I thought it
means), IMHO, the expected behaviour is to complain that it is
already in there.
- if it means "assure the file/dir is in the repository", IMHO, it
should not complain about files already being in the repository.
Well, that might have been already obvious to all of you. To me, it
was not. ;-)
Presumed that the above observation will be agreed upon, one can
deduct that a simple "svn should always be silent" about such files
(as has been suggested) or "svn should always complain" is not
reasonable, but depends on what a command should mean and therefore
the probable expected behaviour would be.
The funny thing is, that while my intuition (awry thing, it is) tells
me "svn add <file/dir>" means the first, it also says that
"svn add -R <dir>" means the second for all recursive checks, i.e. I
would only expect it to give an warning, if there was no file in <dir>
to add at all (even if <dir> was already in the repository).
Ah, and by the way, "svn add -R ." can be used reaonably instead of
"svn add -R *" and would only result in one message in case everything
is already added.[1] So there is an valid alternative to avoid the
mass of annoying messages "*" provokes, if the existing behaviour is
kept.
OTOH, I cannot think of any consequential damage that could result
from changing the current behaviour in the suggested way.
Regards,
Benjamin.
[1] Well, "svn add -R ." will not leave out files starting with dot
(on UNIX systems) which is probably what was meant with "*"
anyhow: add everything, except files on ignore list(s).
(does it indeed ignore files on ignore list? I hope so ;-)
Re: svn add ignoring versioned files (was: Re: Searching Properties)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Colin D Bennett <cb...@radsoft.com> writes:
> Does anyone see a problem with simply ignoring files, even if explicitly
> specified (as with "svn add -R *" or "svn add *")? I wouldn't mind svn
> silently ignoring already-added files.
So we simply declare 'svn add' to be idempotent (I love that word).
Sure, I see no problem with that. Anyone else?
-K
> On Tuesday 03 September 2002 10:26 am, Karl Fogel wrote:
> > Do you mean just 'svn add -R'? I can see why that should not error on
> > already-versioned objects, but if you do 'svn add -R *', that's
> > different -- it's explicitly naming some objects, so maybe it should
> > error if they're already versioned.
> > ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn add ignoring versioned files (was: Re: Searching Properties)
Posted by Colin D Bennett <cb...@radsoft.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Does anyone see a problem with simply ignoring files, even if explicitly
specified (as with "svn add -R *" or "svn add *")? I wouldn't mind svn
silently ignoring already-added files.
On Tuesday 03 September 2002 10:26 am, Karl Fogel wrote:
> Do you mean just 'svn add -R'? I can see why that should not error on
> already-versioned objects, but if you do 'svn add -R *', that's
> different -- it's explicitly naming some objects, so maybe it should
> error if they're already versioned.
> ...
- --
Colin D. Bennett <cb...@radsoft.com>
[ RADSoft: Rapid Engineering Specialists ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD4DBQE9dPh0hU94DiH2eqQRAsdYAJ9n2OcPr9bOVL3iYm8Yj1kiZH5tTACXS2+D
WCv6R+PaK1l2TqhFKzUOBQ==
=j1YC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn add ignoring versioned files (was: Re: Searching Properties)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Colin D Bennett <cb...@radsoft.com> writes:
> +1 on "svn add" ignoring already versioned files.
>
> It's very convenient to be able to add all your new files with "svn
> add -R *", and I can't think of a reason I care to be told if a file
> already exists in subversion.
Do you mean just 'svn add -R'? I can see why that should not error on
already-versioned objects, but if you do 'svn add -R *', that's
different -- it's explicitly naming some objects, so maybe it should
error if they're already versioned.
There's no issue about this for 'svn add' yet. There are issues for
'svn plist' (#774) and 'svn log' (#777). It would be fine to make one
for 'svn add', or to extend the existing issue for plist, but perhaps
first we should decide whether "*" changes the behavior...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
svn add ignoring versioned files (was: Re: Searching Properties)
Posted by Colin D Bennett <cb...@radsoft.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 on "svn add" ignoring already versioned files.
It's very convenient to be able to add all your new files with "svn add -R *",
and I can't think of a reason I care to be told if a file already exists in
subversion.
On Tuesday 03 September 2002 08:35 am, cmpilato@collab.net wrote:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> There exists a similar issue already filed with 'svn add -R *'.
> Perhaps we should just make a general claim about such things:
>
> svn add -R * silently ignores already-versioned things
> all other operations silently ignore unversioned things
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
- --
Colin D. Bennett <cb...@radsoft.com>
[ RADSoft: Rapid Engineering Specialists ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9dPMZhU94DiH2eqQRAr1nAJ9A9gfQy/OogLWeeKmIuz4CNolV5wCbB3UM
pEwT+ltuJBT95OoyySpxXR4=
=RwYU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Searching Properties
Posted by Trampas Stern <ts...@dacaudio.com>.
The reason I was asking about this topic was that I wanted to store some
information as meta data for latter referencing. For example I was
thinking about having sign-offs for documents/source code. That is a
group of people would "sign off" that the code was golden. Then this
could be stored as meta data. Latter before final release I could search
for all sources that were not signed off or the ones that were.
Thanks for a wonderful product
Trampas
-----Original Message-----
From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
Sent: Tuesday, September 03, 2002 11:22 AM
To: cmpilato@collab.net
Cc: Ben Collins-Sussman; Trampas Stern; dev@subversion.tigris.org
Subject: Re: Searching Properties
cmpilato@collab.net writes:
> There exists a similar issue already filed with 'svn add -R *'.
> Perhaps we should just make a general claim about such things:
>
> svn add -R * silently ignores already-versioned things
> all other operations silently ignore unversioned things
We probably don't want *all* other operations to silently ignore
unversioned things, though. We might want some to do that... Not
sure. Kind of low priority right now, I guess, but if someone has
some great guiding principle for this, that would help.
Note that issue #774 already exists for plist, and #777 for log.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
cmpilato@collab.net writes:
> There exists a similar issue already filed with 'svn add -R *'.
> Perhaps we should just make a general claim about such things:
>
> svn add -R * silently ignores already-versioned things
> all other operations silently ignore unversioned things
We probably don't want *all* other operations to silently ignore
unversioned things, though. We might want some to do that... Not
sure. Kind of low priority right now, I guess, but if someone has
some great guiding principle for this, that would help.
Note that issue #774 already exists for plist, and #777 for log.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
> > Well, my first instinct was to run
> >
> > svn proplist -v -R * | grep "color : green"
> >
> > ...or something like that.
> >
> > But it seems that 'svn proplist' bails out completely if it hits an
> > unversioned resource. Ugh. :-(
>
> Just curious, why did you need the "*" anyway? If you ran plist with
> -R, shouldn't that be enough?
>
> I agree that the result above was ugly. Should we call it a bug?
> 'svn plist' takes versioned resources as arguments, so perhaps passing
> it an unversioned resource should error. On the other hand, it might
> be a lot more user-friendly if we just silently ignored unversioned
> items. Thoughts?
There exists a similar issue already filed with 'svn add -R *'.
Perhaps we should just make a general claim about such things:
svn add -R * silently ignores already-versioned things
all other operations silently ignore unversioned things
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by Daniel Berlin <db...@dberlin.org>.
On Wed, 4 Sep 2002, Benjamin Pflugmann wrote:
> Hello.
>
> Replying more to the original mail...
>
> On Tue 2002-09-03 at 18:18:25 +0200, Alexis Huxley wrote:
> > > svn pl -vR
> > >
> > > Of course the only problem now is that the verbose output of 'svn
> > > proplist' isn't very friendly for piping through grep. If I were to
> > > pipe through "grep 'color : green'", I'd see the matching lines, but
> > > have no idea which items the matching properties were attached to.
> > > That's because proplist outputs pairs of lines:
> > >
> > > Properties on 'INSTALL':
> > > svn:keywords : LastChangedDate
> > > Properties on 'gen-make.py':
> > > svn:executable : on
> > > Properties on 'packages/freebsd/subversion':
> > > svn:ignore : work
> > >
> > > Hmmmmmmmmmm.
> >
> > If you like in a GNU universe, then pipe the result of
> > the svn command through
> >
> > sed ':b;/:$/{;N;s/:\n[ ]*//;bb;}'
>
> Always being confused by sed commands except "s///" (have to look this
> up afterwards)
Seriously.
If his message had stopped there, could anyone actually tell whether
that was a real sed command, or memory corruption causing his mailer
to send the message like that?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hello.
Replying more to the original mail...
On Tue 2002-09-03 at 18:18:25 +0200, Alexis Huxley wrote:
> > svn pl -vR
> >
> > Of course the only problem now is that the verbose output of 'svn
> > proplist' isn't very friendly for piping through grep. If I were to
> > pipe through "grep 'color : green'", I'd see the matching lines, but
> > have no idea which items the matching properties were attached to.
> > That's because proplist outputs pairs of lines:
> >
> > Properties on 'INSTALL':
> > svn:keywords : LastChangedDate
> > Properties on 'gen-make.py':
> > svn:executable : on
> > Properties on 'packages/freebsd/subversion':
> > svn:ignore : work
> >
> > Hmmmmmmmmmm.
>
> If you like in a GNU universe, then pipe the result of
> the svn command through
>
> sed ':b;/:$/{;N;s/:\n[ ]*//;bb;}'
Always being confused by sed commands except "s///" (have to look this
up afterwards), I would have suggested (also expecting a GNU universe ;):
svn pl -vR | grep '^Properties\|color : green' | grep -v -B1 '^Properties'
which would also handle multiple properties.
> Not sure if it'll choke on multiple properties, but
> the necessary adaption should be difficult.
HTH,
Benjamin.
Re: Searching Properties
Posted by Alexis Huxley <ah...@gmx.net>.
> svn pl -vR
>
> Of course the only problem now is that the verbose output of 'svn
> proplist' isn't very friendly for piping through grep. If I were to
> pipe through "grep 'color : green'", I'd see the matching lines, but
> have no idea which items the matching properties were attached to.
> That's because proplist outputs pairs of lines:
>
> Properties on 'INSTALL':
> svn:keywords : LastChangedDate
> Properties on 'gen-make.py':
> svn:executable : on
> Properties on 'packages/freebsd/subversion':
> svn:ignore : work
>
> Hmmmmmmmmmm.
If you like in a GNU universe, then pipe the result of
the svn command through
sed ':b;/:$/{;N;s/:\n[ ]*//;bb;}'
(that's a space and a tab in the square brackets) before piping
that on into the grep.
Not sure if it'll choke on multiple properties, but
the necessary adaption should be difficult.
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
> > Well, my first instinct was to run
> >
> > svn proplist -v -R * | grep "color : green"
> >
> > ...or something like that.
> >
> > But it seems that 'svn proplist' bails out completely if it hits an
> > unversioned resource. Ugh. :-(
>
> Just curious, why did you need the "*" anyway? If you ran plist with
> -R, shouldn't that be enough?
Oh! Duh.
Yeah, I just ran this command:
svn pl -vR
...and it worked perfectly on an implicit-dot-target.
Of course the only problem now is that the verbose output of 'svn
proplist' isn't very friendly for piping through grep. If I were to
pipe through "grep 'color : green'", I'd see the matching lines, but
have no idea which items the matching properties were attached to.
That's because proplist outputs pairs of lines:
Properties on 'INSTALL':
svn:keywords : LastChangedDate
Properties on 'gen-make.py':
svn:executable : on
Properties on 'packages/freebsd/subversion':
svn:ignore : work
Hmmmmmmmmmm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Well, my first instinct was to run
>
> svn proplist -v -R * | grep "color : green"
>
> ...or something like that.
>
> But it seems that 'svn proplist' bails out completely if it hits an
> unversioned resource. Ugh. :-(
Just curious, why did you need the "*" anyway? If you ran plist with
-R, shouldn't that be enough?
I agree that the result above was ugly. Should we call it a bug?
'svn plist' takes versioned resources as arguments, so perhaps passing
it an unversioned resource should error. On the other hand, it might
be a lot more user-friendly if we just silently ignored unversioned
items. Thoughts?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Searching Properties
Posted by Ben Collins-Sussman <su...@collab.net>.
"Trampas Stern" <ts...@dacaudio.com> writes:
> I was wondering if it was possible to search the properties meta data
> using subversion? Like find all files/folders which has property 'color'
> set to green.
Well, my first instinct was to run
svn proplist -v -R * | grep "color : green"
...or something like that.
But it seems that 'svn proplist' bails out completely if it hits an
unversioned resource. Ugh. :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org