RE: Subversion checked-out files not indexed in Windows search

2014-03-12 Thread Gareth McCaughan
Ivan Zhakov wrote:

> It looks like serious issue. Could you please file issue in Subversion
> issue tracker: http://subversion.tigris.org/issues

Done. Issue #4478. 

-- 
g 



Re: Subversion checked-out files not indexed in Windows search

2014-03-12 Thread Ivan Zhakov
On 10 March 2014 18:25, Gareth McCaughan
 wrote:
> It appears that files checked out using Subversion (1.7 onwards)
> are marked as not indexable by Windows search. The way in which
> this happens appears to be as follows:
>
> When the WC is created:
>
> 1. .svn directory is created, and marked as hidden and not indexable.
> 2. .svn/tmp directory is created, and inherits that not-indexable
>property. (Or maybe it's given it explicitly; I haven't checked.)
>
> On checkout:
>
> 1. Temporary file is created under .svn, and accordingly gets its
>not-indexable flag set.
> 2. Temporary file is moved to its proper location; this doesn't
>cause the not-indexable flag to be cleared.
>
> So the point is that the NOT_CONTENT_INDEXABLE attribute on a
> directory doesn't exactly mean "don't search inside this directory"
> but "make files created in this directory searchable". Then when
> they get moved elsewhere they retain that unsearchability.
>
> (If skeptical, you can see this "by hand" on a Windows machine,
> as follows: Create a directory A and subdirectory A\B. Right-click
> on B, select "Properties", select "Advanced", uncheck the
> allow-indexing box. Create two files A\B\C.txt and A\B\D.txt
> and put the word "wombat" in each. Now right-click D.txt,
> select "Properties", select "Advanced", and *check* the
> allow-indexing box; and drag C.txt out of A\B and into A.
> Now, in A, search for "wombat" using Windows Search. It will
> find D.txt even though it's in the unsearchable folder A\B,
> and it will not find C.txt even though it's in the searchable
> folder A, because what actually matters is the attributes on
> the files.)
>
> *
>
> Windows Search is of course generally a poor tool for searching
> source code, but this still seems fairly clearly (1) unintended
> and (2) undesirable.
>
> Should I file an issue? If not, will someone else?
>
> *
>
> I am not familiar with the code responsible for this, but
> a little browsing suggests that the rename is being done
> in svn_stream__install_stream (called from run_file_install
> in libsvn_wc/workqueue.c) by a call to SetFileInformationByHandle,
> and that this function is capable of changing the file attributes
> at the same time as doing the rename. I make no claim that
> this would actually be a good solution.
>
> *
>
> (Note 1. This seems to have been reported informally a couple
> of times before, but I don't see that it's ever received an
> official answer, had an issue filed in the Subversion issue
> tracker, or been fixed. Apologies if it has and I've missed it.)
>
> (Note 2. I have observed the behaviour described above on
> Windows 7 using svn 1.7.5, and on Windows 8 using svn 1.8.3.
> There is nothing in the CHANGES file to suggest it's likely
> to have been fixed since then, but I can check with the latest
> release if that's necessary.)
>
> (Note 3. I am not subscribed to users@ but will check for
> replies in the online archives; best to Cc: me, though, if
> you have questions or comments you want to be sure I'll see.)
>
It looks like serious issue. Could you please file issue in Subversion
issue tracker:
http://subversion.tigris.org/issues

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com


Re: Switch to Translation project for Subversion?

2014-03-12 Thread Lübbe TortoiseSVN
Hi Folks,

Since I haven't contributed to the subversion translation for a long time
(one reason being the system used and imho too much bureaucracy), my words
shouldn't weigh too much.

I'd like to make another suggestion: at TortoiseSVN we switched to
transifex.com a few years ago and we are very happy with it. If Subversion
moved there, I'd help with the translations again. Both projects could
profit from synergies.

Cheers
- Lübbe

--
Please help me get more space on Dropbox :)
https://www.dropbox.com/referrals/NTIwMzcxNjI5
   ___
  oo  // \\  "De Chelonian Mobile"
 (_,\/ \_/ \ TortoiseSVN
   \ \_/_\_/>The coolest Interface to (Sub)Version Control
   /_/   \_\ http://tortoisesvn.net  PGP Key ID 0x23F511AB


Re: svn commit: r1575418 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.h fs_fs.c fs_fs.h pack.c structure

2014-03-12 Thread Ivan Zhakov
On 11 March 2014 21:56, Stefan Fuhrmann  wrote:
> On Tue, Mar 11, 2014 at 1:23 PM, Ivan Zhakov  wrote:
>>
>> On 8 March 2014 01:35,   wrote:
>> > Author: stefan2
>> > Date: Fri Mar  7 21:35:54 2014
>> > New Revision: 1575418
>> >
>> > URL: http://svn.apache.org/r1575418
>> > Log:
>> > Enable FSFS format 7 repositories to be packed without completely
>> > blocking commits.  We simply introduce a separate lock file for
>> > 'svnadmin pack' and take out the global write lock for packing
>> > revprops and switching the shard to "packed" state.
>> >
>> > Most of the run time is spent building the revision pack file
>> > and does not require any synchronization with writers.
>> >
>> [...]
>>
>> > @@ -1987,10 +2005,33 @@ svn_fs_fs__pack(svn_fs_t *fs,
>> >  apr_pool_t *pool)
>> >  {
>> >struct pack_baton pb = { 0 };
>> > +  fs_fs_data_t *ffd = fs->fsap_data;
>> > +  svn_error_t *err;
>> > +
>> >pb.fs = fs;
>> >pb.notify_func = notify_func;
>> >pb.notify_baton = notify_baton;
>> >pb.cancel_func = cancel_func;
>> >pb.cancel_baton = cancel_baton;
>> > -  return svn_fs_fs__with_write_lock(fs, pack_body, &pb, pool);
>> > +
>> > +  if (ffd->format >= SVN_FS_FS__MIN_PACK_LOCK_FORMAT)
>> > +{
>> > +  /* Newer repositories provide a pack operation specific lock.
>> > + Acquire it to prevent concurrent packs. */
>> > +  apr_pool_t *subpool = svn_pool_create(pool);
>> What is the reason for using subpool here? Could you please document
>> it if any, otherwise it looks very confusing.
>
>
> Done in r1576427.
>
Thanks! It's clearer now. But I have suggestions for this code:
1. It seems mutex is missed for POSIX platform where file lock is
per-process, not per-thread. Like we
fs_fs_shared_data_t->fs_write_lock
2. I think the code will be clearer with explicit
svn_fs_fs__with_pack_lock() function. In this case mutexes and subpool
will be abstracted from pack logic, which is good imho.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com