You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Greg Thomas <th...@omc.bt.co.uk> on 2005/06/01 08:25:59 UTC
Determining which files are treated as binary
Hi,
I'm trying to create a post-commit hook to set the svn:needs-lock
property on binary files - which should be simple enough.
But, I'm having trouble determining which files are treated as binary
by Subversion. When a new file is added, you do get a (binary) note to
indicate this - e.g.
Adding (bin) test.gif
but AFAICT there's no way of pulling this binary status out using
svnlook or another similar command suitable for use from a hook.
What have I missed?
TIA,
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by kf...@collab.net.
Greg Thomas <th...@omc.bt.co.uk> writes:
> >Depending on your OS, here is a one liner that should get you what you
> >want, then cut the end off and run that through xargs again to set the
> >need-lock property.
> >
> >find . -type f | grep -v .svn | xargs svn propget "svn:mime-type" 2>/dev/null | grep application/octet-stream$
>
> That's fine for application/octet-stream files, but what about other
> mime-types - GIFs, PNGs, Word, Excel, etc. I'd need an exhaustive list
> of all binary types. Given that svn has already identified the file as
> binary when it was added, I was hoping to use that identification.
The concept of "binaryness" is a little more complicated in Subversion
that is is in (say) CVS.
The auto-detection of binaryness that Subversion tries to do at
add/import time simply results in the property "svn:mime-type" being
set on the file, with value "application/octet-stream".
On the other hand, if *you* set the svn:mime-type property manually,
and its value begins with anything other than "text/", then Subversion
will treat the file as binary. Well, that's a bit of an
oversimplification: Subversion also treats "image/x-xbitmap" and
"image/x-xpixmap" as textual types, and maybe more will be added in
the future. But the point is, Subversion starts out assuming that a
mime type represents binary data, and then makes exceptions.
Now, for files with no svn:mime-type property, Subversion behaves in a
carefully two-minded way. Subversion won't do any keyword
substitution or newline conversion (both of which are usually bad news
in binary files) unless you set the svn:keywords or svn:eol-style
properties explicitly. On the other hand, Subversion will try to show
diffs for such a file during 'svn diff', and will try to show
line-by-line attribution as part of 'svn blame', both operations that
normally only make sense for text files. The reason for this is that
we don't want to force developers to set an svn:mime-type on all their
source code files just to get such common operations working -- but on
the other hand, we *definitely* don't want to munge the actual data in
the files without some indication from the user that that's okay.
If the FAQ doesn't already have an entry for "binary files",
explaining all this, it probably should. Now comes the part where I
try to seduce you into helping out: would you like to see what
http://subversion.tigris.org/faq.html says on this subject, and
produce a patch if needed?
See
http://subversion.tigris.org/mailing-list-guidelines.html#patches
and the source code for the FAQ is here:
http://svn.collab.net/repos/svn/trunk/www/faq.html
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [svn] Re: [Issue 2319] Showing missing properties
Posted by Eli Barzilay <el...@barzilay.org>.
On Jun 2, Thomas Moschny wrote:
> On Thursday 02 June 2005 20:20, Eli Barzilay wrote:
> > On Jun 2, kfogel@collab.net wrote:
> > > Well, the full-list comparison script is the idea I was suggesting
> > >
> > > :-).
> >
> > It will be difficult to bundle this up in a robust script. OTOH, it
> > would probably be trivial to change proplist.
>
> Here's a script that might to what you want, and it's rather short
> :-) Maybe the sed part can be made more robust.
>
> #! /bin/bash
>
> comm -2 -3 \
> <( svn ls -R . | sort ) \
> <( ( svn propget -R svn:eol-style . ;
> svn propget -R svn:mime-type . ) |
> sed 's,^\(.*\) - [^ ]*$,\1,' |
> sort -u )
Well... That does work, and it's better than my version (I just added
a "| grep -v '/$'" to the `svn ls' part), but I'd say that a script
that uses two stdin redirections, and a two levels of nested subshells
is only short in its physical size... (BTW, I don't think that there
is a way to make the sed expression better -- you want the first .* to
be non-greedy, but IIRC sed is pretty limited...)
Now the real exercise would be to make that into something that can be
put on a FAQ, with instructions that are sufficient for random people
to copy, use, and modify for other situations and other properties.
This is, IMO, the impossible part.
So I still think that there is a point in adding a command line flag.
For my own usage such hacks are enough so I'll shut up now.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 2319] Showing missing properties
Posted by Thomas Moschny <mo...@ipd.uni-karlsruhe.de>.
On Thursday 02 June 2005 20:20, Eli Barzilay wrote:
> On Jun 2, kfogel@collab.net wrote:
> > Well, the full-list comparison script is the idea I was suggesting
> >
> > :-).
>
> It will be difficult to bundle this up in a robust script. OTOH, it
> would probably be trivial to change proplist.
Here's a script that might to what you want, and it's rather short :-)
Maybe the sed part can be made more robust.
#! /bin/bash
comm -2 -3 \
<( svn ls -R . | sort ) \
<( ( svn propget -R svn:eol-style . ;
svn propget -R svn:mime-type . ) |
sed 's,^\(.*\) - [^ ]*$,\1,' |
sort -u )
Regards,
Thomas
Re: [Issue 2319] Showing missing properties
Posted by Norbert Unterberg <nu...@gmail.com>.
02 Jun 2005 12:26:12 -0500, kfogel@collab.net <kf...@collab.net>:
> > My suggestion was to add a flag to proplist that will list everything,
> > just not showing the properties for paths that lack them, and a
> > similar flag to propget.
>
> We try not to add flags for every conceivable use case. We'd grow a
> lot of flags, most of which would not be used by most users, and
> they'd take up a lot of space in the documentation and help output.
I also think this is a common case. I too once wanted to set the
svn:eol-style property on all *.c and *.h files in a working copy
folder, and I found that very hard. The problem was that the folder
contained some ignored *.h files that were not under version control:
* The simple "svn propset svn:eol-style native *.h" did fail on the
first unversioned *.h and stopped. [note: I have seen some discussion
on the list about this one, so I do not know if this changed already
in 1.2]
* The check what files did not have the propery failed, because "svn
proplist svn:ignore *.h" did not show the files that did not have the
property. I ended up in printing a list of both file lists and
compared the manually :-(
I believe svn has a very small list of available flags (if you do not
count the standard flags that work for basically every command, like
--username --password --recursive etc). I think it would not do much
harm to add another, though I fully understand your defensive policy
about adding new flags.
On the other hand, maybe we do not need a new flag but a modified
default behaviour? When I do a "attrib *.h" in my windows command
shell, I expect to see a list of _all_ *.h files and their attributes,
including the files that don't have any attribute set. Why not make
subversion behave that way? Or is there a "more typical" use case that
requires subversion to omit the files that lack that property?
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 2319] Showing missing properties
Posted by Eli Barzilay <el...@barzilay.org>.
On Jun 2, kfogel@collab.net wrote:
> Eli Barzilay <el...@barzilay.org> writes:
> > That's exactly the issue... The thing that I wanted was to catch
> > all files that don't have either svn:mime-type or svn:eol-style.
> > Running:
> >
> > svn propget -R <prop> .
> >
> > will not show files that *don't* have the property, and running
> >
> > svn proplist -Rv .
> >
> > will not show files that have no properties. One solution would
> > be to use one of these, then compare that to the list of existing
> > files. Another solution would be the script I wrote. The first
> > is faster, but requires more work, and I was in my normal
> > lazy-hacker mood.
>
> Well, the full-list comparison script is the idea I was suggesting
> :-).
It will be difficult to bundle this up in a robust script. OTOH, it
would probably be trivial to change proplist.
> > My suggestion was to add a flag to proplist that will list
> > everything, just not showing the properties for paths that lack
> > them, and a similar flag to propget. propget is trickier, since
> > you don't want to see
> >
> > > propget svn:mime-type foo
> > foo -
> >
> > or
> >
> > > propget svn:mime-type foo
> > foo - no value
>
> We try not to add flags for every conceivable use case. We'd grow a
> lot of flags, most of which would not be used by most users, and
> they'd take up a lot of space in the documentation and help output.
1. This particular case (svn:eol-style and svn:mime-type) seem like
they are common problems. It seems reasonable therefore to add
some flag that will make it possible to write some short entry in
the FAQ or in the book, which tells people how to run it to detect
potential problems.
2. Since this seems to be a common problem, and if you add it to a FAQ
or to the book, then I don't think it will be a feature that gets
used by three people.
3. I consider this on the same convenience level as --stop-on-copy.
It is possible to get by without it, but soon enough you write a
script to help you. Later on when you want to make it available
for others, things get much more complicated since you actually
have to parse the output instead of relying on log messages that
don't have confusing content. Adding a flag is natural in this
case since no hacking is done, and the addition to the source is
minimal.
4. I did say that propget is trickier. For the purpose of such scan,
I'd be happy with just a proplist thing.
5. Obviously, YYMV...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 2319] Showing missing properties
Posted by kf...@collab.net.
Eli Barzilay <el...@barzilay.org> writes:
> That's exactly the issue... The thing that I wanted was to catch all
> files that don't have either svn:mime-type or svn:eol-style. Running:
>
> svn propget -R <prop> .
>
> will not show files that *don't* have the property, and running
>
> svn proplist -Rv .
>
> will not show files that have no properties. One solution would be to
> use one of these, then compare that to the list of existing files.
> Another solution would be the script I wrote. The first is faster,
> but requires more work, and I was in my normal lazy-hacker mood.
Well, the full-list comparison script is the idea I was suggesting :-).
> My suggestion was to add a flag to proplist that will list everything,
> just not showing the properties for paths that lack them, and a
> similar flag to propget. propget is trickier, since you don't want
> to see
>
> > propget svn:mime-type foo
> foo -
>
> or
>
> > propget svn:mime-type foo
> foo - no value
We try not to add flags for every conceivable use case. We'd grow a
lot of flags, most of which would not be used by most users, and
they'd take up a lot of space in the documentation and help output.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 2319] Showing missing properties
Posted by Eli Barzilay <el...@barzilay.org>.
On Jun 2, kfogel@collab.net wrote:
> Eli Barzilay <el...@barzilay.org> writes:
> > There was a discussion that indirectly lead me to post that. SOrry
> > for not making a direct connection.
> > I posted something a short while ago:
> >
> > http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=32649
> >
> > It has the script I had to write because of that problem. It
> > works but it is requires invoking svn two times for each file, so
> > it's very slow.
>
> Why not invoke Subversion on entire trees of files, instead of on one
> file at a time?
That's exactly the issue... The thing that I wanted was to catch all
files that don't have either svn:mime-type or svn:eol-style. Running:
svn propget -R <prop> .
will not show files that *don't* have the property, and running
svn proplist -Rv .
will not show files that have no properties. One solution would be to
use one of these, then compare that to the list of existing files.
Another solution would be the script I wrote. The first is faster,
but requires more work, and I was in my normal lazy-hacker mood.
My suggestion was to add a flag to proplist that will list everything,
just not showing the properties for paths that lack them, and a
similar flag to propget. propget is trickier, since you don't want
to see
> propget svn:mime-type foo
foo -
or
> propget svn:mime-type foo
foo - no value
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 2319] Showing missing properties
Posted by kf...@collab.net.
Eli Barzilay <el...@barzilay.org> writes:
> There was a discussion that indirectly lead me to post that. SOrry
> for not making a direct connection.
> I posted something a short while ago:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=32649
>
> It has the script I had to write because of that problem. It works
> but it is requires invoking svn two times for each file, so it's very
> slow.
Why not invoke Subversion on entire trees of files, instead of on one
file at a time?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [Issue 2319] Showing missing properties
Posted by Eli Barzilay <el...@barzilay.org>.
On Jun 2, kfogel@tigris.org wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2319
> [...]
> Closing as invalid. elibarzilay, would you mind bringing this up on
> the users@ list first, and then on the dev@ list if you sense
> general demand for a feature like this from users?
>
> I think discussing it first on the lists would help narrow down, or
> even eliminate, the problem. For example, a script that combined
> the outputs of 'svn proplist' and 'svn ls' in the obvious way could
> accomplish this pretty easily. (This sort of brainstorming is why
> we have the prominent yellow notice on the top of
> http://subversion.tigris.org/project_issues.html; if you haven't
> seen that notice, take a look.)
There was a discussion that indirectly lead me to post that. SOrry
for not making a direct connection.
I posted something a short while ago:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=32649
It has the script I had to write because of that problem. It works
but it is requires invoking svn two times for each file, so it's very
slow.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [svn] Re: Determining which files are treated as binary
Posted by Eli Barzilay <el...@barzilay.org>.
On Jun 2, Thomas Moschny wrote:
> On Thursday 02 June 2005 16:55, Christopher Ness wrote:
> > I think this will work:
> >
> > find . -! -path '*/.svn/*' -type f | \
> > xargs svn propget "svn:mime-type" 2>/dev/null | \
> > grep -v "- text/"
>
> This will not work if there are filenames with spaces in it, and especially
> not for files named e.g. 'foobar - text.doc'.
>
> What about this:
>
> find . -! -path '*/.svn/*' -type f -exec sh -c \
> 'if test "`svn propget svn:mime-type $0 2>/dev/null '\
> '| cut -f1 -d/`" != "text" ; then echo $0 ; fi' \{\} \;
>
> But of course this is somewhat slower, because svn propget is executed for
> each file.
IIUC, you have to do it that way, since `svn propget' will not display
anything for files with no svn:mime-type property.
Anyway, this is my hack -- it shows the eol-style too, and uses `file'
to look for files with weird eols.
----------------------------------------------------------------------
#!/bin/sh
find . -name .svn -type d -prune -o -type f -print \
| \
while true; do
read f
if [ "x$f" = "x" ]; then exit; fi
echo "$f:" \
"{`svn propget svn:mime-type \"${f}@BASE\"`}" \
"{`svn propget svn:eol-style \"${f}@BASE\"`}" \
"{`file \"$f\" | egrep -o '(CR|LF|NEL|CRLF(.*LF)?)'`}"
done
----------------------------------------------------------------------
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by Thomas Moschny <mo...@ipd.uni-karlsruhe.de>.
On Thursday 02 June 2005 16:55, Christopher Ness wrote:
> I think this will work:
>
> find . -! -path '*/.svn/*' -type f | \
> xargs svn propget "svn:mime-type" 2>/dev/null | \
> grep -v "- text/"
This will not work if there are filenames with spaces in it, and especially
not for files named e.g. 'foobar - text.doc'.
What about this:
find . -! -path '*/.svn/*' -type f -exec sh -c \
'if test "`svn propget svn:mime-type $0 2>/dev/null '\
'| cut -f1 -d/`" != "text" ; then echo $0 ; fi' \{\} \;
But of course this is somewhat slower, because svn propget is executed for
each file.
Regards,
Thomas
Re: Determining which files are treated as binary
Posted by Dominic Anello <da...@danky.com>.
On 2005-06-02 10:16:05 -0400, Dominic Anello wrote:
----8<----
> IIRC, everything without a text/* mime-type will get treated as binary
> so just look for non-text mime-types:
>
> find . -! -path '*/.svn/*' -type f | \
> | xargs svn propget "svn:mime-type" 2>/dev/null | grep -v 'text/'
Sorry to reply to myself, but even easier (and more efficient) would be:
svn pg -R svn:mime-type . | grep -v ' - text/'
Re: Determining which files are treated as binary
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Thu, 2 Jun 2005 10:16:05 -0400, Dominic Anello <da...@danky.com>
wrote:
>On 2005-06-02 09:11:51 +0100, Greg Thomas wrote:
>> On Wed, 01 Jun 2005 14:31:08 -0400, Christopher Ness
>> <ch...@nesser.org> wrote:
>>
>> >On Wed, 2005-06-01 at 09:25 +0100, Greg Thomas wrote:
>> >> I'm trying to create a post-commit hook to set the svn:needs-lock
>> >> property on binary files - which should be simple enough.
>
>Properties *are* version-controlled. Revision properties aren't, but
>svn:mime-type isn't a rev prop.
Oops. It's a fair cop. I'm still struggling to get my head around what
a rev prop is, tbh.
> Furthermore, if you look at the help
>for svn propset, you'll see that ps without the --revprop flag only
>accepts PATHs as an argument, so you have to check out a working copy.
>Not to say it can't be done, but your hook script will both create
>additional revisions and need to manage working copies.
Well, it's certainly doable, it just adds an extra level of
complexity. As it's only an extra revision for every commit that
adds/updates a binary file that doesn't have the svn:needs-lock
property, it's not like it's going to fill up the repository with
small commits. Besides, it's not like I'm going to run out of revision
numbers ;-)
>IIRC, everything without a text/* mime-type will get treated as binary
>so just look for non-text mime-types:
Well, that's /nearly/ what the help for svn propset says - files
without a mime type are also treated as text (which I'd not noticed
before), though the example you gave will work fine. But given the
complexity of the post-commit script, I think I'll need something like
Perl;
1. Check all committed files for binary-ness (sic) without svn:needs-lock
2. If some found, checkout the highest directory with an affected file
3. update binary files
4. Commit changes
5. Cleanup
Yuck. Wonder how long before svn propset works on a URL?
http://svn.haxx.se/users/archive-2003-09/0715.shtml says 30 minutes,
but that was nearly two years ago ;-)
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by Christopher Ness <ch...@nesser.org>.
On Thu, 2005-06-02 at 10:16 -0400, Dominic Anello wrote:
> IIRC, everything without a text/* mime-type will get treated as binary
> so just look for non-text mime-types:
>
> find . -! -path '*/.svn/*' -type f | \
> | xargs svn propget "svn:mime-type" 2>/dev/null | grep -v 'text/'
Good call on the negation of he mime type. The only thing that scares
me is if you have a directory called "text" in the repository you might
miss a few files since those entries will be filtered out by the last
grep.
I also like the fancy find arguments, but I'm too lazy to look them up
in the man page every time so I just chained together some grep's. ;)
I think this will work:
find . -! -path '*/.svn/*' -type f | \
xargs svn propget "svn:mime-type" 2>/dev/null | \
grep -v "- text/"
The last grep uses the fact that svn propget prints the output in the
format of "PATH - MIMETYPE\n", ie:
pear/tests/test-pkg6/pkg6-2.0b1.tgz - application/octet-stream
Cheers,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
10:48:19 up 23:55, 1 user, load average: 0.03, 0.07, 0.08
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On 02 Jun 2005 11:37:52 -0500, kfogel@collab.net wrote:
>Again, don't do this in a pre- or post-commit hook. It's important
>that repository txns remain exactly as clients committed them,
>otherwise the client's working copy will be out-of-date but the client
>won't know it.
I'm missing something here. What's the problem with doing a commit on
a post-commit hook. Yes, the clients working copy will be out of date
(a revision behind). But that's exactly the same as if a user had come
along and manually done the commit.
I can understand why you wouldn't want to do it in a pre-commit hook,
though, as the repository and wc would have different ideas of what
constitutes a single revision.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by kf...@collab.net.
Dominic Anello <da...@danky.com> writes:
> > I'm not planning to alter a commit transaction. I'm modifying a
> > property (which isn't version controlled anyway) *after* a commit
> > transaction. I understand why you can't modify a commit in a
> > pre-commit hook, but I don't see any issues in updating the repository
> > in a post-commit hook.
> ----8<----
>
> Properties *are* version-controlled. Revision properties aren't, but
> svn:mime-type isn't a rev prop. Furthermore, if you look at the help
> for svn propset, you'll see that ps without the --revprop flag only
> accepts PATHs as an argument, so you have to check out a working copy.
> Not to say it can't be done, but your hook script will both create
> additional revisions and need to manage working copies.
You are right about the different kinds of properties.
However, it is technically possible (though we strongly recommend
against it!) to modify versioned-controlled properties in the
repository without using a working copy. Just use the svn_repos_* and
svn_fs_* APIs, either directly or through some language bindings.
Again, don't do this in a pre- or post-commit hook. It's important
that repository txns remain exactly as clients committed them,
otherwise the client's working copy will be out-of-date but the client
won't know it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by Dominic Anello <da...@danky.com>.
On 2005-06-02 09:11:51 +0100, Greg Thomas wrote:
> On Wed, 01 Jun 2005 14:31:08 -0400, Christopher Ness
> <ch...@nesser.org> wrote:
>
> >On Wed, 2005-06-01 at 09:25 +0100, Greg Thomas wrote:
> >> I'm trying to create a post-commit hook to set the svn:needs-lock
> >> property on binary files - which should be simple enough.
> >
> >Just to nip this in the bud. You *cannot* modify a commit transaction
> >with a hook script. You can only reject it.
>
> I'm not planning to alter a commit transaction. I'm modifying a
> property (which isn't version controlled anyway) *after* a commit
> transaction. I understand why you can't modify a commit in a
> pre-commit hook, but I don't see any issues in updating the repository
> in a post-commit hook.
----8<----
Properties *are* version-controlled. Revision properties aren't, but
svn:mime-type isn't a rev prop. Furthermore, if you look at the help
for svn propset, you'll see that ps without the --revprop flag only
accepts PATHs as an argument, so you have to check out a working copy.
Not to say it can't be done, but your hook script will both create
additional revisions and need to manage working copies.
> >Depending on your OS, here is a one liner that should get you what you
> >want, then cut the end off and run that through xargs again to set the
> >need-lock property.
> >
> >find . -type f | grep -v .svn | xargs svn propget "svn:mime-type" 2>/dev/null | grep application/octet-stream$
>
> That's fine for application/octet-stream files, but what about other
> mime-types - GIFs, PNGs, Word, Excel, etc. I'd need an exhaustive list
> of all binary types. Given that svn has already identified the file as
> binary when it was added, I was hoping to use that identification.
IIRC, everything without a text/* mime-type will get treated as binary
so just look for non-text mime-types:
find . -! -path '*/.svn/*' -type f | \
| xargs svn propget "svn:mime-type" 2>/dev/null | grep -v 'text/'
-Dominic
Re: Determining which files are treated as binary
Posted by Greg Thomas <th...@omc.bt.co.uk>.
On Wed, 01 Jun 2005 14:31:08 -0400, Christopher Ness
<ch...@nesser.org> wrote:
>On Wed, 2005-06-01 at 09:25 +0100, Greg Thomas wrote:
>> I'm trying to create a post-commit hook to set the svn:needs-lock
>> property on binary files - which should be simple enough.
>
>Just to nip this in the bud. You *cannot* modify a commit transaction
>with a hook script. You can only reject it.
I'm not planning to alter a commit transaction. I'm modifying a
property (which isn't version controlled anyway) *after* a commit
transaction. I understand why you can't modify a commit in a
pre-commit hook, but I don't see any issues in updating the repository
in a post-commit hook.
...
>> But, I'm having trouble determining which files are treated as binary
>> by Subversion. When a new file is added, you do get a (binary) note to
>> indicate this - e.g.
>> Adding (bin) test.gif
>> but AFAICT there's no way of pulling this binary status out using
>> svnlook or another similar command suitable for use from a hook.
>
>Depending on your OS, here is a one liner that should get you what you
>want, then cut the end off and run that through xargs again to set the
>need-lock property.
>
>find . -type f | grep -v .svn | xargs svn propget "svn:mime-type" 2>/dev/null | grep application/octet-stream$
That's fine for application/octet-stream files, but what about other
mime-types - GIFs, PNGs, Word, Excel, etc. I'd need an exhaustive list
of all binary types. Given that svn has already identified the file as
binary when it was added, I was hoping to use that identification.
Greg
--
This post represents the views of the author and does
not necessarily accurately represent the views of BT.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Determining which files are treated as binary
Posted by Christopher Ness <ch...@nesser.org>.
On Wed, 2005-06-01 at 09:25 +0100, Greg Thomas wrote:
> I'm trying to create a post-commit hook to set the svn:needs-lock
> property on binary files - which should be simple enough.
Just to nip this in the bud. You *cannot* modify a commit transaction
with a hook script. You can only reject it.
Your best bet is to have clients use a default configuration file which
identifies the binary files you wish to use.
There is talk about a global config file, but currently it is up to each
client (on the users computer) to determine their configuration.
> But, I'm having trouble determining which files are treated as binary
> by Subversion. When a new file is added, you do get a (binary) note to
> indicate this - e.g.
> Adding (bin) test.gif
> but AFAICT there's no way of pulling this binary status out using
> svnlook or another similar command suitable for use from a hook.
Depending on your OS, here is a one liner that should get you what you
want, then cut the end off and run that through xargs again to set the
need-lock property.
find . -type f | grep -v .svn | xargs svn propget "svn:mime-type" 2>/dev/null | grep application/octet-stream$
You'll get a listing like this:
ext/dom/tests/book.xml.gz - application/octet-stream
ext/xsl/tests/xslt.xsl.gz - application/octet-stream
ext/dba/tests/test.cdb - application/octet-stream
Let me explain, sections are separated by pipes `|'
1. List all the files in the current directory.
2. Filter out files in a .svn directory
3. Ask subversion if the property is set, disregard all error messages
4. Only print the files that are binary, as we could have other
mime-types.
Cheers,
Chris
--
Wireless Group,
McMaster University
finger.localdomain
14:11:52 up 3:19, 1 user, load average: 0.22, 0.18, 0.11
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org