Re: Lock icon, windows 7. Help!

[Stefan]

Hi José,
On 2/20/2017 16:25, José Carlos López wrote:
>
>
> Hola ,recientemente tengo problemas para visualizar el icono de
> BLOQUEO cuando reservo unobjeto para usarlo en tortoise svn (Windows 7).
>
> Los iconos de commit y demás funcionan perfectamenteexcepto el de
> bloqueo.Ya configure la opcion del "editor de registro del sistema"
> (regedit.exe) pero sin éxito.
>
> ¿Que más debo configurar para poder visualizar el icono de bloqueo
> cuando reservo el objeto?
>
> -
>
> Hi, recently i have problems to display the LOCK icon when i save a
> object to use in tortoise svn (Windows 7).
>
> Commit and other icons work perfectly except locking.
>
> Already configure the option of "system registry editor" (regedit.exe)
> but without success. What else should I configure to be able to
> display the lock icon when reserving the object?
>
> Example:
>  
> *I need to see this:*
>  
>  
>  
> *Configuration in regedit:* (They are like priority number one and
> without conflicts with other icons)
>  
> rededit, configuration directory:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers
>  
>  
>  
>  
> ¡thanks!
> -- 
Johan already answered your question on the users mailing list. [1]
Maybe check your spam filter, in case his answer ended up there.
FWIW: He directed you to the appropriate mailing list (Tortoise SVN)
since this is not an issue with SVN but rather with the Tortoise SVN client.

Regards,
Stefan

[1]
http://mail-archives.apache.org/mod_mbox/subversion-users/201702.mbox/%3CCAB84uBXx0zLpuQ_Xj%3DxU4RSO%2B9DhQJhQJBg2U7vFpFtnD8YnYA%40mail.gmail.com%3E



smime.p7s
Description: S/MIME Cryptographic Signature

Lock icon, windows 7. Help!

[José Carlos López]

Hola ,recientemente tengo problemas para visualizar el icono de BLOQUEO
cuando reservo unobjeto para usarlo en tortoise svn (Windows 7). 

Los iconos de commit y demás funcionan perfectamenteexcepto el de
bloqueo.Ya configure la opcion del "editor de registro del sistema"
(regedit.exe) pero sin éxito. 

¿Que más debo configurar para poder visualizar el icono de bloqueo
cuando reservo el objeto? 

-


Hi, recently i have problems to display the LOCK icon when i save a
object to use in tortoise svn (Windows 7). 

Commit and other icons work perfectly except locking. 

Already configure the option of "system registry editor" (regedit.exe)
but without success. What else should I configure to be able to display
the lock icon when reserving the object?

Example: 

I NEED TO SEE THIS: 

CONFIGURATION IN REGEDIT: (They are like priority number one and without
conflicts with other icons) 

rededit, configuration directory: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers

¡thanks! 
-- 

-

José Carlos López Granados
CRC CODING S.A.

   Heredia, Costa Rica

PHONE:(+506) 2261-5145 
MOBILE:(+506) 8558-3839 
FAX: (+506) 2291-3914
E-MAIL: jose.lo...@crccoding.com 
SKYPE: jose_carlos_lg 
www.crccoding.com

 

Re: 1.10.0-alpha1 is up for signing

[Stefan]

On 2/16/2017 15:26, Stefan Sperling wrote:
> The 1.10.1-alpha1 release is finally up for signing.
>
> Full committers, please get this release from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thank you!

Trying to build this release triggers the following build error when
compiling the svn-mergeinfo-normalizer tool for me:

..\..\..\tools\client-side\svn-mergeinfo-normalizer\wc_mergeinfo.c(376):
error C4013: 'svn_hash__sets' undefined; assuming extern returning int [
G:\Projekte\MaxSVN\1.10.0-alpha1\build\win32\vcnet-vcproj\svn-mergeinfo-normalizer.vcxproj]

If I'm not mistaken, the issue got introduced in r1777345 where
svn_hash__sets() is used now. However, svn_has__sets() is only declared
(in svn_hash.h ln251 ff.) if SVN_HASH__GETS_SETS is defined (which atm
is only the case, if SVN_DEBUG is defined). That currently breaks the
release build of that tool for me.

Should this issue be fixed before alpha1 is released (assuming it's not
an issue on my side)?

Regards,
Stefan




smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r1783790 - /subversion/site/publish/docs/release-notes/1.10.html

[Johan Corveleyn]

On Mon, Feb 20, 2017 at 8:50 PM,   wrote:
> Author: jcorvel
> Date: Mon Feb 20 19:50:38 2017
> New Revision: 1783790
>
> URL: http://svn.apache.org/viewvc?rev=1783790=rev
> Log:
> * publish/docs/release-notes/1.10.html: put "keep working copy state" as
>resolution option for local change "deleted directory".
>
> Modified:
> subversion/site/publish/docs/release-notes/1.10.html
>
> Modified: subversion/site/publish/docs/release-notes/1.10.html
> URL: 
> http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.10.html?rev=1783790=1783789=1783790=diff
> ==
> --- subversion/site/publish/docs/release-notes/1.10.html (original)
> +++ subversion/site/publish/docs/release-notes/1.10.html Mon Feb 20 19:50:38 
> 2017
> @@ -350,9 +350,10 @@ href="https://wiki.apache.org/subversion
>  
>any change inside directory
>  
> -update, switch
> +update, switch, merge
>  
> -  ...
> +  keep working copy state (deleted directory),
> +  discarding incoming changes
>  
>
>  

Stefan, I suppose the above is correct (for update, switch and merge),
and corresponds to the (r) (mark as resolved) option, right?

Am I right that the same goes for "delete file" (local change) and
"edit file" (incoming change)? If so I can extend that row from
"delete directory" to "delete item" for the local change.

Is it also possible to revert the local deletion and accept the
incoming change(s) from within the resolver? I think that would be a
nice "alternative action" in this case (but postponing and then
reverting from outside of the resolver seems a bit cumbersome and less
intuitive for the user).

-- 
Johan

Re: Glob syntax for svndumpfilter exclude --pattern

[Julian Foad]

Branko Čibej wrote:

On 20.02.2017 11:23, Julian Foad wrote:

(I noticed a suboptimal edge case: the above example doesn't match the
path '/alpha', because the implementation adds a leading slash to the
specified pattern, making '/*/alpha', and then insists on matching
both slashes literally.)


This is a bug.


Actually, adding the leading slash is not really relevant. The more 
general case is that pattern "/trunk/*/README" won't match path 
"/trunk/README", as a consequence of not treating slash as special in 
paths. A user might well expect it to match, knowing that the pattern 
"/trunk//README" *will* match due to our canonicalizing the input 
patterns before matching. So there is an inconsistency there.


That may not have been intended, but I don't propose we change it now, 
because I can't think of any simple change that would be an improvement.



Everything else is as expected.


Thanks.

- Julian

Re: Glob syntax for svndumpfilter exclude --pattern

[Branko Čibej]

On 20.02.2017 11:23, Julian Foad wrote:
> (I noticed a suboptimal edge case: the above example doesn't match the
> path '/alpha', because the implementation adds a leading slash to the
> specified pattern, making '/*/alpha', and then insists on matching
> both slashes literally.)

This is a bug. Everything else is as expected.

-- Brane

Re: Glob syntax for svndumpfilter exclude --pattern

[Julian Foad]

Julian Foad wrote:

[[[
$ svndumpfilter --help exclude
[...]
  --pattern : Treat the path prefixes as file glob patterns.
]]]


I expanded the help a little in revision 1783741, to include what I felt 
are the most useful brief details:


[[[
$ svndumpfilter --help exclude
[...]
  --pattern: Treat the path prefixes as file glob patterns.
 Glob special characters are '*' '?' '[]' and '\'.
 Character '/' is not treated specially, so
 pattern /*/foo matches paths /a/foo and /a/b/foo.
]]]

- Julian

Glob syntax for svndumpfilter exclude --pattern

[Julian Foad]

The '--pattern' option to svndumpfilter exclude/include was introduced 
in Subversion 1.7 by http://svn.apache.org/r880381 (cc: Brane):


[[[
$ svndumpfilter --help exclude
[...]
  --pattern : Treat the path prefixes as file glob patterns.
]]]

We don't say what sort of glob patterns it accepts, even in the Book 
[1]. In particular, for a customer's use case, I would like to know 
whether it supports matching a variable number of path elements, for 
which a '/**/' syntax is typically used.


Its implementation uses svn_cstring_match_glob_list() which doesn't say 
either. The implementation of that uses apr_fnmatch(flags=0).


apr_fnmatch is documented. In particular it says '*' matches "Any 
sequence of zero or more characters". (We are *not* giving the flag 
APR_FNM_PATHNAME "Slash must be matched by slash".)


So the particular answer I was looking for is that '*' will cross 
multiple path elements:


[[[
  $ svndumpfilter exclude --pattern '*/alpha'
  Excluding prefix patterns:
   '/*/alpha'
  [...]
  Dropped 2 nodes:
   '/foo/alpha'
   '/foo/bar/alpha'
]]]

(I noticed a suboptimal edge case: the above example doesn't match the 
path '/alpha', because the implementation adds a leading slash to the 
specified pattern, making '/*/alpha', and then insists on matching both 
slashes literally.)


- Julian


[1] 
http://svnbook.red-bean.com/nightly/en/svn.ref.svndumpfilter.html#svn.ref.svndumpfilter.sw.pattern

Re: Check SHA vs Content (was: RE: svn commit: r1759233 - /subversion/trunk/subversion/libsvn_wc/questions.c)

[Bert Huijben]

This code is still in trunk without any of the discussed improvements, so
this change is currently part of 1.10.0-alpha1.

If we don't implement the improvements I think we should check if we want
to revert to the 1.0-1.9 behavior before we really look at releasing 1.10.

See discussion below

Bert

On Thu, Sep 8, 2016 at 5:42 PM, Ivan Zhakov  wrote:

> On 5 September 2016 at 19:23, Ivan Zhakov  wrote:
> > On 5 September 2016 at 14:46, Bert Huijben  wrote:
> >>> -Original Message-
> >>> From: i...@apache.org [mailto:i...@apache.org]
> >>> Sent: maandag 5 september 2016 13:33
> >>> To: comm...@subversion.apache.org
> >>> Subject: svn commit: r1759233 -
> >>> /subversion/trunk/subversion/libsvn_wc/questions.c
> >>>
> >>> Author: ivan
> >>> Date: Mon Sep  5 11:32:54 2016
> >>> New Revision: 1759233
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1759233=rev
> >>> Log:
> >>> Use SHA-1 checksum to find whether files are actually modified in
> working
> >>> copy if timestamps don't match.
> >>>
> >>> Before this change we were doing this:
> >>> 1. Compare file timestamps: if they match, assume that files didn't
> change.
> >>> 2. Open pristine file.
> >>> 3. Read properties from wc.db and find whether translation is required.
> >>> 4. Compare filesize with pristine filesize for files that do not
> >>>require translation. Assume that file is modified if the sizes
> differ.
> >>> 5. Compare detranslated contents of working file with pristine.
> >>>
> >>> Now behavior is the following:
> >>> 1. Compare file timestamps: if they match, assume that files didn't
> change.
> >>> 3. Read properties from wc.db and find whether translation is required.
> >>> 3. Compare filesize with pristine filesize for files that do not
> >>>require translation. Assume that file is modified if the sizes
> differ.
> >>> 4. Calculate SHA-1 checksum of detranslated contents of working file
> >>>and compare it with pristine's checksum stored in wc.db.
> >>
> > Hi Bert,
> >
> >> We looked at this before, and this change has pro-s and con-s,
> depending on specific use cases.
> >>
> > Thanks for bringing this to dev@ list, I was not aware that this topic
> > was discussed before.
> >
> [...]
>
> >> If the file happens to be a database file or something similar
> >> there is quite commonly a change in the first 'block', when
> >> there are changes somewhere later on. (Checksum, change
> >> counter, etc.). File formats like sqlite were explicitly designed
> >> for this (and other cheap checks), with a change counter at the start.
> >
> >> I don't think we should 'just change behavior' here, if we don't
> >> have actual usage numbers for our users. Perhaps we should make
> >> this feature configurable... or depending on filesize.
> >>
> >
> > Let me summarize all possible cases that I considered before my
> > change. First of all some definitions:
> > * Text file (T) -- text file that require translation, due to eol
> > style or keywords expansion
> > * Text file (N) -- text file that doesn't require translation
> > * Binary file -- some kind of binary file (database, pdf, zip, docx).
> > Let's assume that user doesn't configure svn:eol-style and
> > svn:keywords for them.
> > * WS -- size of working file
> > * PS -- size of pristine file
> >
> > * Old=xxx -- average required read size for old behavior in terms of
> > working and pristine file sizes
> > * New=xxx -- average required read size for new behavior in terms of
> > working and pristine file sizes
> >
> > 1. Text file (T), not modified:  Old = WS + PS, New = WS
> > 2. Text file (N), not modified:  Old = WS + PS, New = WS
> > 3. Binary file, not modified:  Old = WS + PS, New = WS
> > 4. Text file (T), modified, same size:  Old = 0.5 * WS + 0.5 * PS, New =
> WS
> > 5. Text file (N), modified, same size:  Old = 0.5 * WS + 0.5 * PS, New =
> WS
> > 6. Binary file, modified, same size:  Old = 0.5 * WS + 0.5 * PS, New = WS
> > 7. Text file (T), modified, different size:  Old = 0.5 * WS + 0.5 * PS,
> New = WS
> > 8. Text file (N), modified, different size:  Old = 0, New = 0
> > 9. Binary file, modified, different size:  Old = 0, New = 0
> >
> Hi Bert,
>
> I tested several different binary file formats for no-op/minimal change:
> 1. Microsoft Word (docx): change single character at the end of document:
>- filesize changes (case 9)
>- first change at offset 2,295 of 233,323
> 2. Microsoft Word (doc): change single character at the end of document:
>- filesize didn't change (case 6)
>- first change at offset 540 of 479,232
> 3. sqlite database: insert one row to wc.db (2.5mb)
>- filesize didn't change (case 6)
>- first change at offset 27
> 4. zip archive: change single character in one of many text files (43
> mb uncompressed)
>- filesize changes (case 9)
>- first change at offset 7,182,933 of 10,352,080
> 5. pdf file: no-op change of 800kb file
>- filesize changes (case 9)
>-