Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

I have download a binary package from win32svn[1], and confirmed your issue.

I check the subversion.mo file:

msgunfmt.exe  subversion.mo  -o subversion.po

It looks OK. Then I replaced the intl3_svn.dll file with gettext
0.18.2, it give me another output:

C:\var\tmp>svnadmin upgrade test
已取得版本库锁定。
请稍候；升级版本库可能需要一段时间...

?\205?\234?\179?\201?\201?\253?\188?\182?\161?\163

C:\var\tmp>

The I write a simple test program:

/*
 * cl /MD /I. t-intl.c libintl-8.lib
 */
#include 
#include 
#include 
#include 

#define _(S) gettext(S)

#define PACKAGE_NAME"subversion"

int main(int argc, char **argv)
{
iconv_t cd;
size_t nc, inbytesleft, outbytesleft;
char *msg, msg2[256];

setlocale(LC_ALL,"");
setlocale(LC_CTYPE, "");

bindtextdomain(PACKAGE_NAME, "../share/locale");
/* bind_textdomain_codeset(PACKAGE_NAME, "UTF-8"); */
textdomain(PACKAGE_NAME);

#undef printf

printf(_("Repository lock acquired.\n"
"Please wait; recovering the repository may take some time...\n"));

printf(_("\n"
"Upgrade completed.\n"));

return 0;
}

C:\var\tmp\svn-win32-1.7.9\bin>cl /nologo /MD /I. t-intl.c libintl-8.lib

C:\var\tmp\svn-win32-1.7.9\bin>t-intl.exe
已取得版本库锁定。
请稍候；修复版本库可能需要一段时间...

完成升级。

So this is a binary package build issue, not subversion issue.

[1] 
http://sourceforge.net/projects/win32svn/files/1.7.9/apache24/svn-win32-1.7.9-ap24.zip/download

On Thu, May 23, 2013 at 10:13 AM, QXO  wrote:
> os: windows
> encoding:GBK ( chcp 936 )
>
> The svnadmin  upgrade command output message  first line encoding
> issue(UTF-8 show in GBK),But the second line is right encoding!
>
> 宸插彇寰楃増鏈簱閿佸畾銆?璇风◢鍊欙紱鍗囩骇鐗堟湰搴撳彲鑳介渶瑕佷竴娈垫椂闂?..
>
> 完成升级。
>
> if change console encoding to UTF-8 (chcp 65001),output message is :
>
> Repository lock acquired.
> Please wait; upgrading the repository may take some time...
>
> Upgrade completed.
>
>

Re: svnadmin upgrade output message i18n issue

[Philip Martin]

[bringing in dev@s.a.o]

QXO  writes:

> os: windows
> encoding:GBK ( chcp 936 )
>
> The svnadmin  upgrade command output message  first line encoding
> issue(UTF-8 show in GBK),But the second line is right encoding!
>
> 宸插彇寰楃増鏈簱閿佸畾銆?璇风◢鍊欙紱鍗囩骇鐗堟湰搴撳彲鑳介渶瑕佷竴娈垫椂闂?..
>
> 完成升级。
>
> if change console encoding to UTF-8 (chcp 65001),output message is :
>
> Repository lock acquired.
> Please wait; upgrading the repository may take some time...
>
> Upgrade completed.

Those two lines are produced by different code paths.  The first line
is produced by repos_notify_handler:

  svn_error_clear(svn_stream_printf(feedback_stream, scratch_pool,
 _("Repository lock acquired.\n"
   "Please wait; upgrading the"
   " repository may take some time...\n")));

The second line is produced by:

  SVN_ERR(svn_cmdline_printf(pool, _("\nUpgrade completed.\n")));

and svn_cmdline_printf uses svn_cmdline_cstring_from_utf8 to do a UTF8
to native conversion.

So it appears the UTF8 to native conversion is missing from
repos_notify_handler.  I think repos_notify_handler should be using
svn_stream_printf_from_utf8 rather than svn_stream_printf.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

svn AD authentication

[Stümpfig , Thomas]

Hi everybody,

we are using svn in our company and authenticate against Microsoft Active 
Directory. We are quite happy since years now.
We are working worldwide and hence multi language. Some passwords may have 
german umlaut, $, and other characters.
Users that have these characters in their passwords do not authenticate. Can 
anybody give me a hint where to start searching.
(Apache, MS AD, OS).

Thomas Stümpfig
Global Sales & Services

Siemens Industry Sector
Siemens Industry Software GmbH & Co. KG
Franz-Geuer-Str. 10
50823  Cologne, Germany
Tel.  :+49 (2153) 9107117
Fax  :+49 (221) 20802 988
Mobile :+49 (175) 2205 712
thomas.stuemp...@siemens.com
www.siemens.com/plm


-
Siemens Industry Software GmbH & Co. KG; Anschrift: Franz-Geuer-Str. 10, 50674 
Köln;
Kommanditgesellschaft: Sitz der Gesellschaft: Köln; Registergericht: 
Amtsgericht Köln, HRA 28227;
Geschäftsführung und persönlich haftender Gesellschafter: Siemens Industry 
Software Management GmbH;
Geschäftsführer: Urban August, Daniel Trebes; Sitz der Gesellschaft: Köln; 
Registergericht: Amtsgericht Köln, HRB 70858

subversion-1.8.0-rc2: diff_test 60 fails

[Tobias Bading]

Hello everyone,

I'm having a bit of trouble with subversion-1.8.0-rc2 on my Ubuntu Lucid 
(x86_64) machine. "make check" or "./diff_tests.py 60" (in directory 
subversion/tests/cmdline) fails with:


---

W: =
Expected '3449_spurious' and actual '3449_spurious' in status tree are 
different!

=
EXPECTED NODE TO BE:
=
 * Node name:   3449_spurious
Path:   svn-test-work/working_copies/diff_tests-60/3449_spurious
Contents:   None
Properties: {}
Attributes: {'status': 'M ', 'wc_rev': '2'}
Children:  None (node is probably a file)
=
ACTUAL NODE FOUND:
=
 * Node name:   3449_spurious
Path:   svn-test-work/working_copies/diff_tests-60/3449_spurious
Contents:   None
Properties: {}
Attributes: {'status': '  ', 'wc_rev': '2'}
Children:  None (node is probably a file)

W: ACTUAL STATUS TREE:
svntest.wc.State(wc_dir, {
  ''  : Item(status=' M', wc_rev='2'),
  'A' : Item(status='  ', wc_rev='2'),
  'A/B'   : Item(status='  ', wc_rev='2'),
  'A/B/F' : Item(status='  ', wc_rev='2'),
  'A/B/E' : Item(status='  ', wc_rev='2'),
  'A/B/E/alpha'   : Item(status='  ', wc_rev='2'),
  'A/B/E/beta': Item(status='  ', wc_rev='2'),
  'A/B/lambda': Item(status='  ', wc_rev='2'),
  'A/D'   : Item(status='  ', wc_rev='2'),
  'A/D/H' : Item(status='  ', wc_rev='2'),
  'A/D/H/omega'   : Item(status='  ', wc_rev='2'),
  'A/D/H/psi' : Item(status='  ', wc_rev='2'),
  'A/D/H/chi' : Item(status='  ', wc_rev='2'),
  'A/D/gamma' : Item(status='  ', wc_rev='2'),
  'A/D/G' : Item(status='  ', wc_rev='2'),
  'A/D/G/tau' : Item(status='  ', wc_rev='2'),
  'A/D/G/pi'  : Item(status='  ', wc_rev='2'),
  'A/D/G/rho' : Item(status='  ', wc_rev='2'),
  'A/C'   : Item(status='  ', wc_rev='2'),
  'A/mu'  : Item(status='  ', wc_rev='2'),
  '3449_spurious' : Item(status='  ', wc_rev='2'),
  'iota'  : Item(status='  ', wc_rev='2'),
})
W: CWD: [...]/subversion-1.8.0-rc2/subversion/tests/cmdline
W: EXCEPTION: SVNTreeUnequal
Traceback (most recent call last):
  File 
"[...]/subversion-1.8.0-rc2/subversion/tests/cmdline/svntest/main.py", 
line 1550, in run

rc = self.pred.run(sandbox)
  File 
"[...]/subversion-1.8.0-rc2/subversion/tests/cmdline/svntest/testcase.py", 
line 176, in run

return self.func(sandbox)
  File "./diff_tests.py", line 3878, in no_spurious_conflict
svntest.actions.run_and_verify_status(wc_dir, expected_status)
  File 
"[...]/subversion-1.8.0-rc2/subversion/tests/cmdline/svntest/actions.py", line 
1479, in run_and_verify_status

status_tree.compare_and_display('status', actual_status)
  File 
"[...]/subversion-1.8.0-rc2/subversion/tests/cmdline/svntest/wc.py", 
line 344, in compare_and_display

raise svntest.tree.SVNTreeUnequal
SVNTreeUnequal
FAIL:  diff_tests.py 60: no spurious conflict on update

---

It seems that the test fails to prepare the working copy for the actual 
test. The "merge -c4 ^/" does not work as expected. Instead of merging 
the changes of file 3449_spurious into the working copy, only a 
svn:mergeinfo property is added to the working copy root.


Revision 4 itself seems fine in the repository. 
"[...]/subversion/svn/svn diff -c4 ^/" appears to show the correct 
changes in 3449_spurious.


Once the test fails, the incomplete merge is repeatable in directory 
subversion/tests/cmdline/svn-test-work/working_copies/diff_tests-60 by 
executing "[...]/subversion/svn/svn revert -R ." and then the merge 
again. The merge fails to update file 3449_spurious every time, no 
matter whether the last argument of the merge is "^/", 
"^/3449_spurious", 
"file://[...]/repositories/diff_tests-60/3449_spurious", or 
"file://[...]/repositories/diff_tests-60/3449_spurious". If the last 
argument refers to 3449_spurious, then a svn:mergeinfo property is added 
to file 3449_spurious in the working copy, otherwise the property is 
added to the root directory of the working copy. But the contents of 
file 3449_spurious are never changed :-(. (The file's timestamp doesn't 
change either.)


However, once I execute "[...]/svn revert -R .", "[...]/svn update", and 
"[...]/svn update -r2" in the working copy, the merge works just fine 
afterwards. And that "update -r2" is exactly what no_spurious_conflict 
in diff_tests.py does before the faulty merge, if I'm reading the code 
correctly.


Anyone else having this problem?

Ideas are welcome... :-)

Kind regards,
Tobias

Re: svn AD authentication

[Pavel Lyalyakin]

Hello Thomas,

> are using svn in our company and authenticate against Microsoft Active
> Directory. We are quite happy since years now.
>
> We are working worldwide and hence multi language. Some passwords may have
> german umlaut, $, and other characters.
>
> Users that have these characters in their passwords do not authenticate. Can
> anybody give me a hint where to start searching.
>
> (Apache, MS AD, OS).

Non-ASCII symbols (e.g. '£', 'ü', 'ä' etc.) in password are not
supported in plain-text Basic Authentication. For details check this
mailing list thread:
http://mail-archives.apache.org/mod_mbox/subversion-users/201204.mbox/%3c87obqpxnis@stat.home.lan%3E

In order to use special characters in passwords you should consider
advanced authentication methods that do not store and transfer
plain-text passwords over HTTP. As your network is based on Active
Directory the solution would be to setup Single Sign-On / Integrated
Windows AD authentication via Kerberos and/or NTLM.

You may want to try VisualSVN Server Enterprise Edition that perfectly
integrates in Active Directory and provides Single Sign-On out of the
box without any additional configuration.

Integrated Windows Authentication:
http://www.visualsvn.com/server/features/windows-auth/#integrated
VisualSVN Server Features list: http://www.visualsvn.com/server/features/

Thank you.

-- 
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: subversion-1.8.0-rc2: diff_test 60 fails

[Philip Martin]

Tobias Bading  writes:

> However, once I execute "[...]/svn revert -R .", "[...]/svn update",
> and "[...]/svn update -r2" in the working copy, the merge works just
> fine afterwards. And that "update -r2" is exactly what
> no_spurious_conflict in diff_tests.py does before the faulty merge, if
> I'm reading the code correctly.

Yes, the test is doing an update to r2.

The double update should be an overall no-op, but it is making a
difference.  You have to compare the working copy before and after the
double update and determine what has changed.  One would expect the
timestamp of 3449_spurious to get changed by the double update, does
anything else change?  Does the text of 3449_spurious change?  Does the
output of

 svn info 3449_spurious

change?  Does the output of

  svn pl -v

change? Try running

sqlite3 .svn/wc.db "select * from nodes order by local_relpath"
sqlite3 .svn/wc.db "select * from actual_node order by local_relpath"

does anything there change?

If you cannot identify what has changed perhaps you could provide a
tarball containing the repository and the broken working copy.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Commit fails on locked files

[HOUDROGE Rami]

Hi,

I am experiencing a problem that has been reported a couple of times accross 
the web.

1. new file
2. add file
3. commit file
4. lock file
5. modify file
6. commit file

and that last commit fails with the following error :

Cannot verify lock on path '...'; no matching lock-token available.

[cid:part1.03020408.00020306@thalesgroup.com]

I am certain no one stole the lock and I am also certain that, locally, only 
one working copy has the lock.

I found one possible explanation that doesn't help much actually. It says you 
should compile the apache server with the option -enable-pie. 
http://subversion.1072662.n5.nabble.com/Subversion-Llocked-file-could-not-able-to-commit-the-changes-td137837.html

Has anyone experienced this ? Could anyone provide an explanation / solution to 
this problem ?

Thanks in advance,

Rami Houdroge
<>

Re: Commit fails on locked files

[Johan Corveleyn]

On Thu, May 23, 2013 at 3:01 PM, HOUDROGE Rami
 wrote:
>
> Hi,
>
> I am experiencing a problem that has been reported a couple of times accross 
> the web.
>
> 1. new file
> 2. add file
> 3. commit file
> 4. lock file
> 5. modify file
> 6. commit file
>
> and that last commit fails with the following error :
>
> Cannot verify lock on path '...'; no matching lock-token available.
>
>
>
> I am certain no one stole the lock and I am also certain that, locally, only 
> one working copy has the lock.
>
> I found one possible explanation that doesn't help much actually. It says you 
> should compile the apache server with the option -enable-pie. 
> http://subversion.1072662.n5.nabble.com/Subversion-Llocked-file-could-not-able-to-commit-the-changes-td137837.html
>
> Has anyone experienced this ? Could anyone provide an explanation / solution 
> to this problem ?

A couple of questions:
- Which version of SVN client? If not the latest 1.7.x release, can
you try to reproduce with the latest one?
- Does it also reproduce if you insert a 'svn update parent-dir'
between steps 3 and 4? What about an 'svn update root-of-workingcopy'?

(the last questions are not meant to challenge whether or not this is
a bug, but to get a bit more insight into what might be happening)

--
Johan

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 4:17 PM, Philip Martin
 wrote:
> [bringing in dev@s.a.o]
>
> QXO  writes:
>
>> os: windows
>> encoding:GBK ( chcp 936 )
>>
>> The svnadmin  upgrade command output message  first line encoding
>> issue(UTF-8 show in GBK),But the second line is right encoding!
>>
>> 宸插彇寰楃増鏈簱閿佸畾銆?璇风◢鍊欙紱鍗囩骇鐗堟湰搴撳彲鑳介渶瑕佷竴娈垫椂闂?..
>>
>> 完成升级。
>>
>> if change console encoding to UTF-8 (chcp 65001),output message is :
>>
>> Repository lock acquired.
>> Please wait; upgrading the repository may take some time...
>>
>> Upgrade completed.
>
> Those two lines are produced by different code paths.  The first line
> is produced by repos_notify_handler:
>
>   svn_error_clear(svn_stream_printf(feedback_stream, scratch_pool,
>  _("Repository lock acquired.\n"
>"Please wait; upgrading the"
>" repository may take some time...\n")));
>
> The second line is produced by:
>
>   SVN_ERR(svn_cmdline_printf(pool, _("\nUpgrade completed.\n")));
>
> and svn_cmdline_printf uses svn_cmdline_cstring_from_utf8 to do a UTF8
> to native conversion.
>
> So it appears the UTF8 to native conversion is missing from
> repos_notify_handler.  I think repos_notify_handler should be using
> svn_stream_printf_from_utf8 rather than svn_stream_printf.
>

NO.  From GETTEXT(3) man pages:

In both cases, the functions also use the LC_CTYPE locale facet  in
order  to  convert  the translated message from the translator's
codeset to the ***current locale's codeset***, unless overridden by a
prior call to the bind_textdomain_codeset function.

So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
coded, it it encoded to the ***current locale's codeset***.

--
Regards,
Dongsheng

Re: svnadmin upgrade output message i18n issue

[Philip Martin]

Philip Martin  writes:

> So it appears the UTF8 to native conversion is missing from
> repos_notify_handler.  I think repos_notify_handler should be using
> svn_stream_printf_from_utf8 rather than svn_stream_printf.

I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
for 1.8.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 9:11 PM, Philip Martin
 wrote:
> Philip Martin  writes:
>
>> So it appears the UTF8 to native conversion is missing from
>> repos_notify_handler.  I think repos_notify_handler should be using
>> svn_stream_printf_from_utf8 rather than svn_stream_printf.
>
> I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
> for 1.8.
>

As GETTEXT(3) man pages said, If and only if
defined(HAVE_BIND_TEXTDOMAIN_CODESET),
your commit is OK.

So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
svn_cmdline_cstring_from_utf8.

Re: Commit fails on locked files

[HOUDROGE Rami]

Johan,

Thank you for your quick answer. I am using the following versions :

TortoiseSVN 1.7.12, Build 24070 - 64 Bit
Subversion 1.7.9

Concerning the second question, the problem persists after an update of the 
root of working copy (and parent dir).

Cheers,

Rami

Le 23/05/2013 15:06, Johan Corveleyn a écrit :

On Thu, May 23, 2013 at 3:01 PM, HOUDROGE Rami
 wrote:
>
> Hi,
>
> I am experiencing a problem that has been reported a couple of times accross 
> the web.
>
> 1. new file
> 2. add file
> 3. commit file
> 4. lock file
> 5. modify file
> 6. commit file
>
> and that last commit fails with the following error :
>
> Cannot verify lock on path '...'; no matching lock-token available.
>
>
>
> I am certain no one stole the lock and I am also certain that, locally, only 
> one working copy has the lock.
>
> I found one possible explanation that doesn't help much actually. It says you 
> should compile the apache server with the option -enable-pie. 
> http://subversion.1072662.n5.nabble.com/Subversion-Llocked-file-could-not-able-to-commit-the-changes-td137837.html
>
> Has anyone experienced this ? Could anyone provide an explanation / solution 
> to this problem ?

A couple of questions:
- Which version of SVN client? If not the latest 1.7.x release, can
you try to reproduce with the latest one?
- Does it also reproduce if you insert a 'svn update parent-dir'
between steps 3 and 4? What about an 'svn update root-of-workingcopy'?

(the last questions are not meant to challenge whether or not this is
a bug, but to get a bit more insight into what might be happening)

--
Johan

.

Re: svnadmin upgrade output message i18n issue

[Philip Martin]

Dongsheng Song  writes:

> On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>  wrote:
>> Philip Martin  writes:
>>
>>> So it appears the UTF8 to native conversion is missing from
>>> repos_notify_handler.  I think repos_notify_handler should be using
>>> svn_stream_printf_from_utf8 rather than svn_stream_printf.
>>
>> I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
>> for 1.8.
>>
>
> As GETTEXT(3) man pages said, If and only if
> defined(HAVE_BIND_TEXTDOMAIN_CODESET),
> your commit is OK.
>
> So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
> svn_cmdline_cstring_from_utf8.

Are you saying there is a problem with my change?  If there is a problem
doesn't already apply to all other uses of svn_cmdline_cstring_from_utf8?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 9:28 PM, Philip Martin
 wrote:
> Dongsheng Song  writes:
>
>> On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>>  wrote:
>>> Philip Martin  writes:
>>>
 So it appears the UTF8 to native conversion is missing from
 repos_notify_handler.  I think repos_notify_handler should be using
 svn_stream_printf_from_utf8 rather than svn_stream_printf.
>>>
>>> I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
>>> for 1.8.
>>>
>>
>> As GETTEXT(3) man pages said, If and only if
>> defined(HAVE_BIND_TEXTDOMAIN_CODESET),
>> your commit is OK.
>>
>> So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
>> svn_cmdline_cstring_from_utf8.
>
> Are you saying there is a problem with my change?  If there is a problem
> doesn't already apply to all other uses of svn_cmdline_cstring_from_utf8?
>

I thinks so. In the subversion/libsvn_subr/nls.c file:

#ifdef HAVE_BIND_TEXTDOMAIN_CODESET
  bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
#endif /* HAVE_BIND_TEXTDOMAIN_CODESET */

bind_textdomain_codeset only called when HAVE_BIND_TEXTDOMAIN_CODESET
defined. In this case, you can assume GETTEXT(3) returned string is
UTF-8 encoded.

Re: Commit fails on locked files

[Philip Martin]

HOUDROGE Rami  writes:

> I am experiencing a problem that has been reported a couple of times
> accross the web.
>
> 1. new file
> 2. add file
> 3. commit file
> 4. lock file
> 5. modify file
> 6. commit file
>
> and that last commit fails with the following error :
>
> Cannot verify lock on path '...'; no matching lock-token available.
>
> [cid:part1.03020408.00020306@thalesgroup.com]
>
> I am certain no one stole the lock and I am also certain that,
> locally, only one working copy has the lock.

Run 'svn info' on the working copy file to see the lock token in the
working copy.  Run 'svn info' on the URL to see the lock token in the
repository.  How do the locks compare (token, username, date)?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Commit fails on locked files

[HOUDROGE Rami]

They're the same.

Local file :
Lock Token: opaquelocktoken:2a0cb251-8e5c-4b2e-9eb2-282abb2d67e6
Lock Owner: houdroge
Lock Created: 2013-05-23 15:14:37 +0200 (jeu., 23 mai 2013)

Remote file :
Lock Token: opaquelocktoken:2a0cb251-8e5c-4b2e-9eb2-282abb2d67e6
Lock Owner: houdroge
Lock Created: 2013-05-23 15:14:37 +0200 (jeu., 23 mai 2013)



Le 23/05/2013 15:59, Philip Martin a écrit :

HOUDROGE Rami 
 writes:

> I am experiencing a problem that has been reported a couple of times
> accross the web.
>
> 1. new file
> 2. add file
> 3. commit file
> 4. lock file
> 5. modify file
> 6. commit file
>
> and that last commit fails with the following error :
>
> Cannot verify lock on path '...'; no matching lock-token available.
>
> [cid:part1.03020408.00020306@thalesgroup.com]
>
> I am certain no one stole the lock and I am also certain that,
> locally, only one working copy has the lock.

Run 'svn info' on the working copy file to see the lock token in the
working copy.  Run 'svn info' on the URL to see the lock token in the
repository.  How do the locks compare (token, username, date)?

--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svnadmin upgrade output message i18n issue

[Philip Martin]

Dongsheng Song  writes:

> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>  wrote:
>> Dongsheng Song  writes:
>>
>>> On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>>>  wrote:
 Philip Martin  writes:

> So it appears the UTF8 to native conversion is missing from
> repos_notify_handler.  I think repos_notify_handler should be using
> svn_stream_printf_from_utf8 rather than svn_stream_printf.

 I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
 for 1.8.

>>>
>>> As GETTEXT(3) man pages said, If and only if
>>> defined(HAVE_BIND_TEXTDOMAIN_CODESET),
>>> your commit is OK.
>>>
>>> So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
>>> svn_cmdline_cstring_from_utf8.
>>
>> Are you saying there is a problem with my change?  If there is a problem
>> doesn't already apply to all other uses of svn_cmdline_cstring_from_utf8?
>>
>
> I thinks so. In the subversion/libsvn_subr/nls.c file:
>
> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
>
> bind_textdomain_codeset only called when HAVE_BIND_TEXTDOMAIN_CODESET
> defined. In this case, you can assume GETTEXT(3) returned string is
> UTF-8 encoded.

I still don't understand if you are claiming my change has a problem or
if there is a problem in all uses of svn_cmdline_cstring_from_utf8.

I recall a related thread from last year:

http://svn.haxx.se/dev/archive-2012-08/index.shtml#34
http://mail-archives.apache.org/mod_mbox/subversion-dev/201208.mbox/%3Cop.wilcelggnngjn5@tortoise%3E

I think we assume that the translations are UTF-8.

Is there some code change you think we should make?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svnadmin upgrade output message i18n issue

[Branko Čibej]

On 23.05.2013 16:06, Philip Martin wrote:
> Dongsheng Song  writes:
>
>> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>>  wrote:
>>> Dongsheng Song  writes:
>>>
 On Thu, May 23, 2013 at 9:11 PM, Philip Martin
  wrote:
> Philip Martin  writes:
>
>> So it appears the UTF8 to native conversion is missing from
>> repos_notify_handler.  I think repos_notify_handler should be using
>> svn_stream_printf_from_utf8 rather than svn_stream_printf.
> I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
> for 1.8.
>
 As GETTEXT(3) man pages said, If and only if
 defined(HAVE_BIND_TEXTDOMAIN_CODESET),
 your commit is OK.

 So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
 svn_cmdline_cstring_from_utf8.
>>> Are you saying there is a problem with my change?  If there is a problem
>>> doesn't already apply to all other uses of svn_cmdline_cstring_from_utf8?
>>>
>> I thinks so. In the subversion/libsvn_subr/nls.c file:
>>
>> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
>>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
>> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
>>
>> bind_textdomain_codeset only called when HAVE_BIND_TEXTDOMAIN_CODESET
>> defined. In this case, you can assume GETTEXT(3) returned string is
>> UTF-8 encoded.
> I still don't understand if you are claiming my change has a problem or
> if there is a problem in all uses of svn_cmdline_cstring_from_utf8.
>
> I recall a related thread from last year:
>
> http://svn.haxx.se/dev/archive-2012-08/index.shtml#34
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201208.mbox/%3Cop.wilcelggnngjn5@tortoise%3E
>
> I think we assume that the translations are UTF-8.

We do not "assume" the translations are UTF-8, we require them to be.

http://subversion.apache.org/docs/community-guide/l10n.html#po-mo-requirements

-- Brane 

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: Commit fails on locked files

[Johan Corveleyn]

> Le 23/05/2013 15:59, Philip Martin a écrit :
>
> HOUDROGE Rami  writes:
>
>> I am experiencing a problem that has been reported a couple of times
>> accross the web.
>>
>> 1. new file
>> 2. add file
>> 3. commit file
>> 4. lock file
>> 5. modify file
>> 6. commit file
>>
>> and that last commit fails with the following error :
>>
>> Cannot verify lock on path '...'; no matching lock-token available.
>>
>> [cid:part1.03020408.00020306@thalesgroup.com]
>>
>> I am certain no one stole the lock and I am also certain that,
>> locally, only one working copy has the lock.
>
> Run 'svn info' on the working copy file to see the lock token in the
> working copy.  Run 'svn info' on the URL to see the lock token in the
> repository.  How do the locks compare (token, username, date)?
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
>

On Thu, May 23, 2013 at 4:04 PM, HOUDROGE Rami
 wrote:
> They're the same.
>
> Local file :
> Lock Token: opaquelocktoken:2a0cb251-8e5c-4b2e-9eb2-282abb2d67e6
> Lock Owner: houdroge
> Lock Created: 2013-05-23 15:14:37 +0200 (jeu., 23 mai 2013)
>
> Remote file :
> Lock Token: opaquelocktoken:2a0cb251-8e5c-4b2e-9eb2-282abb2d67e6
> Lock Owner: houdroge
> Lock Created: 2013-05-23 15:14:37 +0200 (jeu., 23 mai 2013)
>
>

Rami,

Can you please try to reproduce this with commandline svn, and provide
us a full transcript of what you do to reproduce this (maybe with a
test file / test repository)? Or even better, a fully self-contained
reproduction script (I guess you're on Windows, so see [1] for a
template of a .bat reproduction script).

[1] http://subversion.apache.org/docs/community-guide/repro-template.bat

--
Johan

Anyone have solid SCM experience?

[Samantha Tilney]

I'm looking for a contractor with experience rolling out Git-- if
interested, please feel free to contact me at samantha.til...@mondo.com

Thanks!

My direct client, an Electronic Inspection company has an immediate need
for a SCM Contractor

Duration: 3-6 months
Location: Natick, MA
Salary/Rate: D.O.E
Start Date: ASAP

*Responsibilities:*
The Role
The role involves working with the development team to determine if Git is
a viable source code management system for use at Client Site. The work
will include evaluation of Git security and determining the Git
configuration that should deployed. If Git is determined to be a viable
option the project will also include transition existing source code base
from ClearCase and Git to the new SCM environment.

Tasks performed in this job include:


·  Determine the Git configuration that Client should use.

·  Identify and test Git add-on components.

·  Define the corporate standard for Git servers and clients.

·  Help to create policies and procedures for working with Git / SCM.

·  Transition existing source code base from ClearCase to Git, as required.

·  Transition existing Git systems to the new corporate standard Git
configuration.


*Qualifications/Requirements:*


·  Expert in administering and using Git for source code management.

·  Deep knowledge of source code management

·  Good working knowledge of Linux, Windows and Apache.

·  Some knowledge / experience with Git GUI front ends desirable.

·  Excellent written and verbal communication skills

·  Familiar with ClearCase version control system is desirable.

·  Experience with scripting languages such as Perl or Python is desirable


-- 

*Samantha Tilney*|*  **Technical Recruiter*

*———*

*MONDO** ** *| * 617.651.8091*  | * *samantha.til...@mondo.com

200 State St, Boston,MA 02110  |  mondo.com
*Follow us on** Twitter   *|*  **Engage
with us on 
Facebook
*

Re: Tags - Symbolic names instead of Directory copy?

[BRM]

> From: Thorsten Schöning 

> To: users@subversion.apache.org
> Sent: Thursday, May 23, 2013 2:49 AM
> Subject: Re: Tags - Symbolic names instead of Directory copy?
>G uten Tag Varnau, Steve (Seaquest R&D),
> am Donnerstag, 23. Mai 2013 um 01:57 schrieben Sie:
> 
>>  In my opinion, the same semantics work less well for tags. My
>>  biased mind-set is that a “tag” is a name identifying a specific
>>  version of code (a cross product of “branch” and “revision”).
> 
> I don't see the point, as you already know that it's not handled that
> way in Subversion and you need to make the same conclusions for tags
> and branches.
> 
>>  In
>>  subversion, a directory-path@revision, (e.g., ^/trunk@123) give the
>>  correct semantics of a tag.
> 
> Simply use them that way, like you said for branches.
> 
>>  But a “tag” that is the result of an svn cp (e.g.,
>>  ^/tags/TRUNK-STABLE) does not give the same semantics.
> 
> Because from my understanding you compare two things which have
> nothing to do with each other: One is how branches and tags are
> created, both the same way, but the other is what happens afterwards
> to each. As branches and tags are technically the same, only differing
> by convention, they of course work equally and therefore need to share
> the same semantics.
> 
>>  Checkout is fine, I get the right version of the code. Update
>>  gives me the message that my workspace is up to date.
> 
> Only if it is update, meaning no one ever committed anything to your
> tag. If commits were made, your working copy would not be up to date
> anymore, of course. It sounds to me like you compare branches with per
> convention immutable tags to come to the conclusion that both have
> different semantics. But that's not the case, just a result of your
> immutable tags convention.
> 
>>  So I silently
>>  miss the fact that the latest code changes I wanted to pull in are
>>  over on trunk, not on this tag I checked out from.
> 
> Because with checking out a tag and keeping it immutable you want that
> tag and not trunk. Or what's the reason for checking out that special
> tag at all? Especially if you know it's immutable, if it wouldn't be
> immutable you of course would get new commits.

I think he's thinking of CVS style tags, which are mutable in that you can 
modify which version of different
files have the tag. So everyone works on HEAD and a "STABLE" tag progresses 
across it
as developers decide different ports are stable.

However, as you've mentioned and was more at length discusses elsewhere
that's simply not have SVN works.

A similar kind of workflow for SVN would be:

Main work: /trunk
Trunk Stable "tag" or branch: /tags/trunk-stable or /branches/trunk-stable

Do work in /trunk, as things are declared "stable" merge to 
/branches/trunk-stable.

While I have in the past been able to sympathize with people looking for 
CVS-style tags
(and still do to some extent), I think Subversion style Tags are far more 
superior
primarily from the fact that you can track any changes that are happening to 
the tag,
which you could not do with CVS.

Ben
>

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 10:06 PM, Philip Martin
 wrote:
> Dongsheng Song  writes:
>
>> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>>  wrote:
>>> Dongsheng Song  writes:
>>>
 On Thu, May 23, 2013 at 9:11 PM, Philip Martin
  wrote:
> Philip Martin  writes:
>
>> So it appears the UTF8 to native conversion is missing from
>> repos_notify_handler.  I think repos_notify_handler should be using
>> svn_stream_printf_from_utf8 rather than svn_stream_printf.
>
> I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
> for 1.8.
>

 As GETTEXT(3) man pages said, If and only if
 defined(HAVE_BIND_TEXTDOMAIN_CODESET),
 your commit is OK.

 So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
 svn_cmdline_cstring_from_utf8.
>>>
>>> Are you saying there is a problem with my change?  If there is a problem
>>> doesn't already apply to all other uses of svn_cmdline_cstring_from_utf8?
>>>
>>
>> I thinks so. In the subversion/libsvn_subr/nls.c file:
>>
>> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
>>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
>> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
>>
>> bind_textdomain_codeset only called when HAVE_BIND_TEXTDOMAIN_CODESET
>> defined. In this case, you can assume GETTEXT(3) returned string is
>> UTF-8 encoded.
>
> I still don't understand if you are claiming my change has a problem or
> if there is a problem in all uses of svn_cmdline_cstring_from_utf8.
>
> I recall a related thread from last year:
>
> http://svn.haxx.se/dev/archive-2012-08/index.shtml#34
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201208.mbox/%3Cop.wilcelggnngjn5@tortoise%3E
>
> I think we assume that the translations are UTF-8.
>
> Is there some code change you think we should make?
>

Even ALL the translations are UTF-8, GETTEXT(3) still return the
string encoded by the ***current locale's codeset***.

 Here is sniped from the GETTEXT(3) man pages:

In both cases, the functions also use the LC_CTYPE locale facet  in
order  to  convert  the translated message from the translator's
codeset to the ***current locale's codeset***, unless overridden by a
prior call to the bind_textdomain_codeset function.

So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
coded, it it encoded to the ***current locale's codeset***.

I think the best solution is: DO NOTconvert the GETTEXT(3) returned
messages, write it ***AS IS***, since GETTEXT(3)  already do the
correct conversion for us.

RE: Anyone have solid SCM experience?

[Grierson, David]

Did anyone else love the irony that this ad was looking for a Git admin and 
didn't mention Subversion in any way whatsoever.

Dg.

--
David Grierson - SDLC Tools 
Specialist
Sky Broadcasting - Customer Business Systems - SDLC Tools
Tel: +44 1506 325100 / Email: 
david.grier...@bskyb.com / Chatter: CBS SDLC 
Tools
Watermark Building, Alba Campus, Livingston, EH54 7HH


Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trade marks of British Sky Broadcasting Group plc and 
are used under licence. British Sky Broadcasting Limited (Registration No. 
2906991), Sky Interactive Limited (Registration No. 3554332), Sky-In-Home 
Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited 
(Registration No. 2340150) are direct or indirect subsidiaries of British Sky 
Broadcasting Group plc (Registration No. 2247735). All of the companies 
mentioned in this paragraph are incorporated in England and Wales and share the 
same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

Re: svnadmin upgrade output message i18n issue

[Erik Huelsmann]

sent from my phone
On May 23, 2013 4:43 PM, "Dongsheng Song"  wrote:
>
> On Thu, May 23, 2013 at 10:06 PM, Philip Martin
>  wrote:
> > Dongsheng Song  writes:
> >
> >> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
> >>  wrote:
> >>> Dongsheng Song  writes:
> >>>
>  On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>   wrote:
> > Philip Martin  writes:
> >
> >> So it appears the UTF8 to native conversion is missing from
> >> repos_notify_handler.  I think repos_notify_handler should be using
> >> svn_stream_printf_from_utf8 rather than svn_stream_printf.
> >
> > I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed
it
> > for 1.8.
> >
> 
>  As GETTEXT(3) man pages said, If and only if
>  defined(HAVE_BIND_TEXTDOMAIN_CODESET),
>  your commit is OK.
> 
>  So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
>  svn_cmdline_cstring_from_utf8.
> >>>
> >>> Are you saying there is a problem with my change?  If there is a
problem
> >>> doesn't already apply to all other uses of
svn_cmdline_cstring_from_utf8?
> >>>
> >>
> >> I thinks so. In the subversion/libsvn_subr/nls.c file:
> >>
> >> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
> >>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
> >> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
> >>
> >> bind_textdomain_codeset only called when HAVE_BIND_TEXTDOMAIN_CODESET
> >> defined. In this case, you can assume GETTEXT(3) returned string is
> >> UTF-8 encoded.
> >
> > I still don't understand if you are claiming my change has a problem or
> > if there is a problem in all uses of svn_cmdline_cstring_from_utf8.
> >
> > I recall a related thread from last year:
> >
> > http://svn.haxx.se/dev/archive-2012-08/index.shtml#34
> >
http://mail-archives.apache.org/mod_mbox/subversion-dev/201208.mbox/%3Cop.wilcelggnngjn5@tortoise%3E
> >
> > I think we assume that the translations are UTF-8.
> >
> > Is there some code change you think we should make?
> >
>
> Even ALL the translations are UTF-8, GETTEXT(3) still return the
> string encoded by the ***current locale's codeset***.
>
>  Here is sniped from the GETTEXT(3) man pages:
>
> In both cases, the functions also use the LC_CTYPE locale facet  in
> order  to  convert  the translated message from the translator's
> codeset to the ***current locale's codeset***, unless overridden by a
> prior call to the bind_textdomain_codeset function.
>
> So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
> coded, it it encoded to the ***current locale's codeset***.

But we call the codeset function to make sure we do not generate output in
the current locale encoding.

> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> messages, write it ***AS IS***, since GETTEXT(3)  already do the
> correct conversion for us.

Well, even though gettext may want us to believe otherwise, this doesn't
work for cross platform applications: e.g. in windows the locale for output
on the console may be different from the locale for other uses. Back when
we went with gettext (2004?), we've hashed this through pretty thoroughly.
I hope that discussion is still available in the archives.

Bye,

Erik.

Re: Anyone have solid SCM experience?

[vishwajeet singh]

On Thu, May 23, 2013 at 8:30 PM, Grierson, David
wrote:

>  Did anyone else love the irony that this ad was looking for a Git admin
> and didn't mention Subversion in any way whatsoever.
>

Yes I did, but thought to ignore :-p

> 
>
> ** **
>
> Dg.
>  --
>
> --
> *David Grierson * –
> SDLC Tools Specialist 
>
> Sky Broadcasting - Customer Business Systems - SDLC Tools
>
> Tel: +44 1506 325100 / Email: david.grier...@bskyb.com / Chatter: CBS
> SDLC 
> Tools
> 
>
> Watermark Building, Alba Campus, Livingston, EH54 7HH
>
> Information in this email including any attachments may be privileged,
> confidential and is intended exclusively for the addressee. The views
> expressed may not be official policy, but the personal views of the
> originator. If you have received it in error, please notify the sender by
> return e-mail and delete it from your system. You should not reproduce,
> distribute, store, retransmit, use or disclose its contents to anyone.
> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks. SKY and the SKY marks are trade
> marks of British Sky Broadcasting Group plc and are used under licence.
> British Sky Broadcasting Limited (Registration No. 2906991), Sky
> Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited
> (Registration No. 2067075) and Sky Subscribers Services Limited
> (Registration No. 2340150) are direct or indirect subsidiaries of British
> Sky Broadcasting Group plc (Registration No. 2247735). All of the companies
> mentioned in this paragraph are incorporated in England and Wales and share
> the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

Re: Anyone have solid SCM experience?

[Samantha Tilney]

I
figured you Subversion fiends might have some experience with Git ;)


On Thu, May 23, 2013 at 11:10 AM, vishwajeet singh wrote:

>
>
>
> On Thu, May 23, 2013 at 8:30 PM, Grierson, David  > wrote:
>
>>  Did anyone else love the irony that this ad was looking for a Git admin
>> and didn't mention Subversion in any way whatsoever.
>>
>
> Yes I did, but thought to ignore :-p
>
>> 
>>
>> ** **
>>
>> Dg.
>>  --
>>
>> --
>> *David Grierson * –
>> SDLC Tools Specialist 
>>
>> Sky Broadcasting - Customer Business Systems - SDLC Tools
>>
>> Tel: +44 1506 325100 / Email: david.grier...@bskyb.com / Chatter: CBS
>> SDLC 
>> Tools
>> 
>>
>> Watermark Building, Alba Campus, Livingston, EH54 7HH
>>
>> Information in this email including any attachments may be privileged,
>> confidential and is intended exclusively for the addressee. The views
>> expressed may not be official policy, but the personal views of the
>> originator. If you have received it in error, please notify the sender by
>> return e-mail and delete it from your system. You should not reproduce,
>> distribute, store, retransmit, use or disclose its contents to anyone.
>> Please note we reserve the right to monitor all e-mail communication
>> through our internal and external networks. SKY and the SKY marks are trade
>> marks of British Sky Broadcasting Group plc and are used under licence.
>> British Sky Broadcasting Limited (Registration No. 2906991), Sky
>> Interactive Limited (Registration No. 3554332), Sky-In-Home Service Limited
>> (Registration No. 2067075) and Sky Subscribers Services Limited
>> (Registration No. 2340150) are direct or indirect subsidiaries of British
>> Sky Broadcasting Group plc (Registration No. 2247735). All of the companies
>> mentioned in this paragraph are incorporated in England and Wales and share
>> the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
>>
>
>
>
> --
> Vishwajeet Singh
> +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn:
> http://www.linkedin.com/in/singhvishwajeet
>



-- 

*Samantha Tilney*|*  **Technical Recruiter*

*———*

*MONDO** ** *| * 617.651.8091*  | * *samantha.til...@mondo.com

200 State St, Boston,MA 02110  |  mondo.com
*Follow us on** Twitter   *|*  **Engage
with us on 
Facebook
*

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 11:02 PM, Erik Huelsmann  wrote:
> sent from my phone
>
>
> On May 23, 2013 4:43 PM, "Dongsheng Song"  wrote:
>>
>> On Thu, May 23, 2013 at 10:06 PM, Philip Martin
>>  wrote:
>> > Dongsheng Song  writes:
>> >
>> >> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>> >>  wrote:
>> >>> Dongsheng Song  writes:
>> >>>
>>  On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>>   wrote:
>> > Philip Martin  writes:
>> >
>> >> So it appears the UTF8 to native conversion is missing from
>> >> repos_notify_handler.  I think repos_notify_handler should be using
>> >> svn_stream_printf_from_utf8 rather than svn_stream_printf.
>> >
>> > I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed
>> > it
>> > for 1.8.
>> >
>> 
>>  As GETTEXT(3) man pages said, If and only if
>>  defined(HAVE_BIND_TEXTDOMAIN_CODESET),
>>  your commit is OK.
>> 
>>  So you should check HAVE_BIND_TEXTDOMAIN_CODESET when you use
>>  svn_cmdline_cstring_from_utf8.
>> >>>
>> >>> Are you saying there is a problem with my change?  If there is a
>> >>> problem
>> >>> doesn't already apply to all other uses of
>> >>> svn_cmdline_cstring_from_utf8?
>> >>>
>> >>
>> >> I thinks so. In the subversion/libsvn_subr/nls.c file:
>> >>
>> >> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
>> >>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
>> >> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
>> >>
>> >> bind_textdomain_codeset only called when HAVE_BIND_TEXTDOMAIN_CODESET
>> >> defined. In this case, you can assume GETTEXT(3) returned string is
>> >> UTF-8 encoded.
>> >
>> > I still don't understand if you are claiming my change has a problem or
>> > if there is a problem in all uses of svn_cmdline_cstring_from_utf8.
>> >
>> > I recall a related thread from last year:
>> >
>> > http://svn.haxx.se/dev/archive-2012-08/index.shtml#34
>> >
>> > http://mail-archives.apache.org/mod_mbox/subversion-dev/201208.mbox/%3Cop.wilcelggnngjn5@tortoise%3E
>> >
>> > I think we assume that the translations are UTF-8.
>> >
>> > Is there some code change you think we should make?
>> >
>>
>> Even ALL the translations are UTF-8, GETTEXT(3) still return the
>> string encoded by the ***current locale's codeset***.
>>
>>  Here is sniped from the GETTEXT(3) man pages:
>>
>> In both cases, the functions also use the LC_CTYPE locale facet  in
>> order  to  convert  the translated message from the translator's
>> codeset to the ***current locale's codeset***, unless overridden by a
>> prior call to the bind_textdomain_codeset function.
>>
>> So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
>> coded, it it encoded to the ***current locale's codeset***.
>
> But we call the codeset function to make sure we do not generate output in
> the current locale encoding.
>
>> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
>> messages, write it ***AS IS***, since GETTEXT(3)  already do the
>> correct conversion for us.
>
> Well, even though gettext may want us to believe otherwise, this doesn't
> work for cross platform applications: e.g. in windows the locale for output
> on the console may be different from the locale for other uses. Back when we
> went with gettext (2004?), we've hashed this through pretty thoroughly. I
> hope that discussion is still available in the archives.
>

As I said in the first email of this thread, gettext 0.18.2 and 0.14.1
give me the different behavior, it seems that gettext 0.14.1 do not do
the correct thing. But do we still need support this OLD and BUGGY
version ?

Re: svnadmin upgrade output message i18n issue

[Philip Martin]

Dongsheng Song  writes:

> Even ALL the translations are UTF-8, GETTEXT(3) still return the
> string encoded by the ***current locale's codeset***.
>
>  Here is sniped from the GETTEXT(3) man pages:
>
> In both cases, the functions also use the LC_CTYPE locale facet  in
> order  to  convert  the translated message from the translator's
> codeset to the ***current locale's codeset***, unless overridden by a
> prior call to the bind_textdomain_codeset function.

We do call bind_textdomain_codeset if it is available so we should be
getting UTF8 translations.

> So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
> coded, it it encoded to the ***current locale's codeset***.
>
> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> messages, write it ***AS IS***, since GETTEXT(3)  already do the
> correct conversion for us.

It's not that simple.  We would have to change almost every error:

svn_error_createf(SVN_ERR_BAD_RELATIVE_PATH, NULL, \
  _("Path '%s' must be an immediate child of " \
"the directory '%s'"), path, relative_to_dir)

and convert variable like 'path' and 'relative_to_dir' from UTF8 to
native before combining with the native translation.

What would be the gain for all that work?  The only problem at present
is a system that doesn't have bind_textdomain_codeset but where gettext
returns the current locale encoding having converted it from the UTF8 in
the file.  Are there any such systems?  What about the opposite problem:
systems that don't have bind_textdomain_codeset and where gettext
returns UTF8 because that is the encoding in the file.  Are there any
systems like that?

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: svnadmin upgrade output message i18n issue

[Erik Huelsmann]

> >
> >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> >> messages, write it ***AS IS***, since GETTEXT(3)  already do the
> >> correct conversion for us.
> >
> > Well, even though gettext may want us to believe otherwise, this doesn't
> > work for cross platform applications: e.g. in windows the locale for
output
> > on the console may be different from the locale for other uses. Back
when we
> > went with gettext (2004?), we've hashed this through pretty thoroughly.
I
> > hope that discussion is still available in the archives.
> >
>
> As I said in the first email of this thread, gettext 0.18.2 and 0.14.1
> give me the different behavior, it seems that gettext 0.14.1 do not do
> the correct thing. But do we still need support this OLD and BUGGY
> version ?

That was not my point nor the point we discussed back then. As long as
gettext tries to convert its translations to *any* encoding, it's flawed by
design, because some systems have multiple active output encodings (e.g.
Windows).

Unless this design has changed between 0.14 and 0.18, gettext() is still as
broken as it was. Translating or not translating doesn't matter: it'll just
be broken on other systems. Too bad the rest of it is actually pretty good.

Bye,

Erik.

Re: Anyone have solid SCM experience?

[Daniel Shahaf]

Samantha Tilney wrote on Thu, May 23, 2013 at 11:12:09 -0400:
> I figured you Subversion fiends might have some experience with Git ;)

So?  This is a mailing list for Subversion user support.  It has 800+
readers, most of whom are not looking for a 3-6 months contract for work
on Git.  That suggests your post was off-topic.

Re: svnadmin upgrade output message i18n issue

[Erik Huelsmann]

Found at least one of the related discussions:

http://svn.haxx.se/dev/archive-2004-05/0078.shtml

bye,

Erik.
On May 23, 2013 5:38 PM, "Erik Huelsmann"  wrote:

>
> > >
> > >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> > >> messages, write it ***AS IS***, since GETTEXT(3)  already do the
> > >> correct conversion for us.
> > >
> > > Well, even though gettext may want us to believe otherwise, this
> doesn't
> > > work for cross platform applications: e.g. in windows the locale for
> output
> > > on the console may be different from the locale for other uses. Back
> when we
> > > went with gettext (2004?), we've hashed this through pretty
> thoroughly. I
> > > hope that discussion is still available in the archives.
> > >
> >
> > As I said in the first email of this thread, gettext 0.18.2 and 0.14.1
> > give me the different behavior, it seems that gettext 0.14.1 do not do
> > the correct thing. But do we still need support this OLD and BUGGY
> > version ?
>
> That was not my point nor the point we discussed back then. As long as
> gettext tries to convert its translations to *any* encoding, it's flawed by
> design, because some systems have multiple active output encodings (e.g.
> Windows).
>
> Unless this design has changed between 0.14 and 0.18, gettext() is still
> as broken as it was. Translating or not translating doesn't matter: it'll
> just be broken on other systems. Too bad the rest of it is actually pretty
> good.
>
> Bye,
>
> Erik.
>

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 11:38 PM, Erik Huelsmann  wrote:
> That was not my point nor the point we discussed back then. As long as
> gettext tries to convert its translations to *any* encoding, it's flawed by
> design, because some systems have multiple active output encodings (e.g.
> Windows).
>

This does not matter. If I open 2 console window, one is CP437, the
other is CP936. Then svn in CP437 windows generate English (ASCII)
output, CP936 windows generate Chinese (GBK/GB18030) output.

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Thu, May 23, 2013 at 11:29 PM, Philip Martin
 wrote:
> Dongsheng Song  writes:
>
>> Even ALL the translations are UTF-8, GETTEXT(3) still return the
>> string encoded by the ***current locale's codeset***.
>>
>>  Here is sniped from the GETTEXT(3) man pages:
>>
>> In both cases, the functions also use the LC_CTYPE locale facet  in
>> order  to  convert  the translated message from the translator's
>> codeset to the ***current locale's codeset***, unless overridden by a
>> prior call to the bind_textdomain_codeset function.
>
> We do call bind_textdomain_codeset if it is available so we should be
> getting UTF8 translations.
>

For non-autotools system, e.g. Windows, user may not define
HAVE_BIND_TEXTDOMAIN_CODESET.

>> So svn_cmdline_printf SHOULD NOT assume the input string is UTF-8
>> coded, it it encoded to the ***current locale's codeset***.
>>
>> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
>> messages, write it ***AS IS***, since GETTEXT(3)  already do the
>> correct conversion for us.
>
> It's not that simple.  We would have to change almost every error:
>
> svn_error_createf(SVN_ERR_BAD_RELATIVE_PATH, NULL, \
>   _("Path '%s' must be an immediate child of " \
> "the directory '%s'"), path, relative_to_dir)
>
> and convert variable like 'path' and 'relative_to_dir' from UTF8 to
> native before combining with the native translation.
>
> What would be the gain for all that work?  The only problem at present
> is a system that doesn't have bind_textdomain_codeset but where gettext
> returns the current locale encoding having converted it from the UTF8 in
> the file.  Are there any such systems?  What about the opposite problem:
> systems that don't have bind_textdomain_codeset and where gettext
> returns UTF8 because that is the encoding in the file.  Are there any
> systems like that?
>

Or we should call bind_textdomain_codeset as possible, and warn the
user if HAVE_BIND_TEXTDOMAIN_CODESET not defined:

#ifdef HAVE_BIND_TEXTDOMAIN_CODESET
  bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
#else
  fprintf(sdterr, "bind_textdomain_codeset not available, or not
configured.  Non-UTF8 locales maybe see garbled output.\n");
#endif /* HAVE_BIND_TEXTDOMAIN_CODESET */

Re: svnadmin upgrade output message i18n issue

[Erik Huelsmann]

One application has multiple active code page settings on Windows. Or
course if your example was the only option, we would not be having this
discussion.

Bye,

Erik.

sent from my phone
On May 23, 2013 6:44 PM, "Dongsheng Song"  wrote:

> On Thu, May 23, 2013 at 11:38 PM, Erik Huelsmann  wrote:
> > That was not my point nor the point we discussed back then. As long as
> > gettext tries to convert its translations to *any* encoding, it's flawed
> by
> > design, because some systems have multiple active output encodings (e.g.
> > Windows).
> >
>
> This does not matter. If I open 2 console window, one is CP437, the
> other is CP936. Then svn in CP437 windows generate English (ASCII)
> output, CP936 windows generate Chinese (GBK/GB18030) output.
>

Re: svnadmin upgrade output message i18n issue

[Dongsheng Song]

On Fri, May 24, 2013 at 12:52 AM, Erik Huelsmann  wrote:
> One application has multiple active code page settings on Windows. Or course
> if your example was the only option, we would not be having this discussion.
>

Very interesting. In my mind, application only can have 1 active
locale in 1 thread. When gettext() got called,  the current locale is
uniquely. Could you give me a sample ?

Regards,
Dongsheng

> Bye,
>
> Erik.
>
> sent from my phone
>
> On May 23, 2013 6:44 PM, "Dongsheng Song"  wrote:
>>
>> On Thu, May 23, 2013 at 11:38 PM, Erik Huelsmann  wrote:
>> > That was not my point nor the point we discussed back then. As long as
>> > gettext tries to convert its translations to *any* encoding, it's flawed
>> > by
>> > design, because some systems have multiple active output encodings (e.g.
>> > Windows).
>> >
>>
>> This does not matter. If I open 2 console window, one is CP437, the
>> other is CP936. Then svn in CP437 windows generate English (ASCII)
>> output, CP936 windows generate Chinese (GBK/GB18030) output.

Re: svnadmin upgrade output message i18n issue

[Philip Martin]

Dongsheng Song  writes:

>> We do call bind_textdomain_codeset if it is available so we should be
>> getting UTF8 translations.
>>
>
> For non-autotools system, e.g. Windows, user may not define
> HAVE_BIND_TEXTDOMAIN_CODESET.

If you build the software with the wrong settings it may not work
properly.  The solution is to build it with the correct settings.
Perhaps you can improve the Windows build.

> Or we should call bind_textdomain_codeset as possible, and warn the
> user if HAVE_BIND_TEXTDOMAIN_CODESET not defined:
>
> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
> #else
>   fprintf(sdterr, "bind_textdomain_codeset not available, or not
> configured.  Non-UTF8 locales maybe see garbled output.\n");
> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */

That error would be annoying if it was a false alarm.  Perhaps we could
verify the correct behaviour: call gettext and check whether the
returned string is valid UTF8?  However, we are not getting reports of
problems so it's probably not worth the effort.  The bug that started
this thread is about the exact opposite: gettext was returning UTF8 and
the output code was failing to convert to locale encoding.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

RE: Tags - Symbolic names instead of Directory copy?

> From: BRM [mailto:bm_witn...@yahoo.com]
> 
> > From: Thorsten Schöning 
> 
> > To: users@subversion.apache.org
> > Sent: Thursday, May 23, 2013 2:49 AM
> > Subject: Re: Tags - Symbolic names instead of Directory copy?
> >G uten Tag Varnau, Steve (Seaquest R&D),  am Donnerstag, 23. Mai 2013
> >um 01:57 schrieben Sie:
> >
> >>  In my opinion, the same semantics work less well for tags. My
> >> biased mind-set is that a “tag” is a name identifying a specific
> >> version of code (a cross product of “branch” and “revision”).
> >
> > I don't see the point, as you already know that it's not handled that
> > way in Subversion and you need to make the same conclusions for tags
> > and branches.
> >
> >>  In
> >>  subversion, a directory-path@revision, (e.g., ^/trunk@123) give the
> >> correct semantics of a tag.
> >
> > Simply use them that way, like you said for branches.
> >
> >>  But a “tag” that is the result of an svn cp (e.g.,
> >>  ^/tags/TRUNK-STABLE) does not give the same semantics.
> >
> > Because from my understanding you compare two things which have
> > nothing to do with each other: One is how branches and tags are
> > created, both the same way, but the other is what happens afterwards
> > to each. As branches and tags are technically the same, only differing
> > by convention, they of course work equally and therefore need to share
> > the same semantics.
> >
> >>  Checkout is fine, I get the right version of the code. Update  gives
> >> me the message that my workspace is up to date.
> >
> > Only if it is update, meaning no one ever committed anything to your
> > tag. If commits were made, your working copy would not be up to date
> > anymore, of course. It sounds to me like you compare branches with per
> > convention immutable tags to come to the conclusion that both have
> > different semantics. But that's not the case, just a result of your
> > immutable tags convention.
> >
> >>  So I silently
> >>  miss the fact that the latest code changes I wanted to pull in are
> >> over on trunk, not on this tag I checked out from.
> >
> > Because with checking out a tag and keeping it immutable you want that
> > tag and not trunk. Or what's the reason for checking out that special
> > tag at all? Especially if you know it's immutable, if it wouldn't be
> > immutable you of course would get new commits.
> 
> I think he's thinking of CVS style tags, which are mutable in that you
> can modify which version of different files have the tag. So everyone
> works on HEAD and a "STABLE" tag progresses across it as developers
> decide different ports are stable.

My example was a poor choice, as I prefer non-mutable tags, but there are 
certainly use-cases for mutable and non-mutable. There are certainly examples 
from other versioning tools. "Baselines" concept in ClearCase, that can be 
defined then locked. But those get too complex very fast. I really prefer the 
kind of simplicity in Svn. 

> 
> However, as you've mentioned and was more at length discusses elsewhere
> that's simply not have SVN works.

Agreed. I understand how Svn works, and it's fine how it works. But I'm arguing 
that I'd like to see an additional type of object that would be useful... 

> 
> A similar kind of workflow for SVN would be:
> 
> Main work: /trunk
> Trunk Stable "tag" or branch: /tags/trunk-stable or /branches/trunk-
> stable
> 
> Do work in /trunk, as things are declared "stable" merge to
> /branches/trunk-stable.
> 
> While I have in the past been able to sympathize with people looking for
> CVS-style tags (and still do to some extent), I think Subversion style
> Tags are far more superior primarily from the fact that you can track
> any changes that are happening to the tag, which you could not do with
> CVS.
> 
> Ben
> > 

Subversion implements a versioned filesystem model (add, cp, mv, rm). If it 
also had a notion of a symlink (ln) that allows reference to path@revision, 
then it gives the same tracking of changes to a "tag" that you mention. But 
then other operations like checkout operate on what it points to. Then you 
really get baseline-label-tag type semantics instead of branch semantics. And 
to get those semantics, you don't really need hook scripts or special 
permissions to treat them specially.

-Steve

Re: Tags - Symbolic names instead of Directory copy?

[BRM]

> From: "Varnau, Steve (Seaquest R&D)" 

> To: BRM ; "users@subversion.apache.org" 
> 
> Cc: Thorsten Schöning 
> Sent: Thursday, May 23, 2013 1:40 PM
> Subject: RE: Tags - Symbolic names instead of Directory copy?
> 
>>  From: BRM [mailto:bm_witn...@yahoo.com]
>> 
>>  > From: Thorsten Schöning 
>> 
>>  > To: users@subversion.apache.org
>>  > Sent: Thursday, May 23, 2013 2:49 AM
>>  > Subject: Re: Tags - Symbolic names instead of Directory copy?
>>  >G uten Tag Varnau, Steve (Seaquest R&D),  am Donnerstag, 23. Mai 
> 2013
>>  >um 01:57 schrieben Sie:
>>  >
>>  >>  In my opinion, the same semantics work less well for tags. My
>>  >> biased mind-set is that a “tag” is a name identifying a specific
>>  >> version of code (a cross product of “branch” and “revision”).
>>  >
>>  > I don't see the point, as you already know that it's not 
> handled that
>>  > way in Subversion and you need to make the same conclusions for tags
>>  > and branches.
>>  >
>>  >>  In
>>  >>  subversion, a directory-path@revision, (e.g., ^/trunk@123) give 
> the
>>  >> correct semantics of a tag.
>>  >
>>  > Simply use them that way, like you said for branches.
>>  >
>>  >>  But a “tag” that is the result of an svn cp (e.g.,
>>  >>  ^/tags/TRUNK-STABLE) does not give the same semantics.
>>  >
>>  > Because from my understanding you compare two things which have
>>  > nothing to do with each other: One is how branches and tags are
>>  > created, both the same way, but the other is what happens afterwards
>>  > to each. As branches and tags are technically the same, only differing
>>  > by convention, they of course work equally and therefore need to share
>>  > the same semantics.
>>  >
>>  >>  Checkout is fine, I get the right version of the code. Update  
> gives
>>  >> me the message that my workspace is up to date.
>>  >
>>  > Only if it is update, meaning no one ever committed anything to your
>>  > tag. If commits were made, your working copy would not be up to date
>>  > anymore, of course. It sounds to me like you compare branches with per
>>  > convention immutable tags to come to the conclusion that both have
>>  > different semantics. But that's not the case, just a result of 
> your
>>  > immutable tags convention.
>>  >
>>  >>  So I silently
>>  >>  miss the fact that the latest code changes I wanted to pull in 
> are
>>  >> over on trunk, not on this tag I checked out from.
>>  >
>>  > Because with checking out a tag and keeping it immutable you want that
>>  > tag and not trunk. Or what's the reason for checking out that 
> special
>>  > tag at all? Especially if you know it's immutable, if it 
> wouldn't be
>>  > immutable you of course would get new commits.
>> 
>>  I think he's thinking of CVS style tags, which are mutable in that you
>>  can modify which version of different files have the tag. So everyone
>>  works on HEAD and a "STABLE" tag progresses across it as 
> developers
>>  decide different ports are stable.
> 
> My example was a poor choice, as I prefer non-mutable tags, but there are 
> certainly use-cases for mutable and non-mutable. There are certainly examples 
> from other versioning tools. "Baselines" concept in ClearCase, that 
> can be defined then locked. But those get too complex very fast. I really 
> prefer 
> the kind of simplicity in Svn. 
> 
>> 
>>  However, as you've mentioned and was more at length discusses elsewhere
>>  that's simply not have SVN works.
> 
> Agreed. I understand how Svn works, and it's fine how it works. But I'm 
> arguing that I'd like to see an additional type of object that would be 
> useful... 

One way to do that would be to have another directory that you have the hook 
scripts configured to make read-only.
So:

/trunk
/branches
/tags
/tags-readOnly

Again, you're going to a hook-script to do it as that is how SVN enforces it 
best.
Yes, there is the permissions structure but there's no easy way to do a 
globular matching like the following:

[/*readOnly*]
@users = r 

That is certainly one feature that would be very handy if ever implemented.
 
>>  A similar kind of workflow for SVN would be:
>>  Main work: /trunk
>>  Trunk Stable "tag" or branch: /tags/trunk-stable or 
> /branches/trunk-
>>  stable
>> 
>>  Do work in /trunk, as things are declared "stable" merge to
>>  /branches/trunk-stable.
>> 
>>  While I have in the past been able to sympathize with people looking for
>>  CVS-style tags (and still do to some extent), I think Subversion style
>>  Tags are far more superior primarily from the fact that you can track
>>  any changes that are happening to the tag, which you could not do with
>>  CVS.
>> 
>>  Ben
>>  > 
> 
> Subversion implements a versioned filesystem model (add, cp, mv, rm). If it 
> also 
> had a notion of a symlink (ln) that allows reference to path@revision, then 
> it 
> gives the same tracking of changes to a "tag" that you mention. But 
> then other operations like checkout operate on what it points to. Then you 
> really get baseline-lab

RE: Tags - Symbolic names instead of Directory copy?

> -Original Message-
> From: BRM [mailto:bm_witn...@yahoo.com]
> Sent: Thursday, May 23, 2013 10:59
> To: Varnau, Steve (Seaquest R&D); users@subversion.apache.org
> Subject: Re: Tags - Symbolic names instead of Directory copy?
> 
> > From: "Varnau, Steve (Seaquest R&D)" 
> 
> > To: BRM ; "users@subversion.apache.org"
> > 
> > Cc: Thorsten Schöning 
> > Sent: Thursday, May 23, 2013 1:40 PM
> > Subject: RE: Tags - Symbolic names instead of Directory copy?
> >
> >>  From: BRM [mailto:bm_witn...@yahoo.com]
> >>
> >>  > From: Thorsten Schöning 
> >>
> >>  > To: users@subversion.apache.org
> >>  > Sent: Thursday, May 23, 2013 2:49 AM  > Subject: Re: Tags -
> >> Symbolic names instead of Directory copy?
> >>  >G uten Tag Varnau, Steve (Seaquest R&D),  am Donnerstag, 23. Mai
> > 2013
> >>  >um 01:57 schrieben Sie:
> >>  >
> >>  >>  In my opinion, the same semantics work less well for tags. My
> >> >> biased mind-set is that a “tag” is a name identifying a specific
> >> >> version of code (a cross product of “branch” and “revision”).
> >>  >
> >>  > I don't see the point, as you already know that it's not
> > handled that
> >>  > way in Subversion and you need to make the same conclusions for
> >> tags  > and branches.
> >>  >
> >>  >>  In
> >>  >>  subversion, a directory-path@revision, (e.g., ^/trunk@123) give
> > the
> >>  >> correct semantics of a tag.
> >>  >
> >>  > Simply use them that way, like you said for branches.
> >>  >
> >>  >>  But a “tag” that is the result of an svn cp (e.g.,  >>
> >> ^/tags/TRUNK-STABLE) does not give the same semantics.
> >>  >
> >>  > Because from my understanding you compare two things which have  >
> >> nothing to do with each other: One is how branches and tags are  >
> >> created, both the same way, but the other is what happens afterwards
> >> > to each. As branches and tags are technically the same, only
> >> differing  > by convention, they of course work equally and therefore
> >> need to share  > the same semantics.
> >>  >
> >>  >>  Checkout is fine, I get the right version of the code. Update
> > gives
> >>  >> me the message that my workspace is up to date.
> >>  >
> >>  > Only if it is update, meaning no one ever committed anything to
> >> your  > tag. If commits were made, your working copy would not be up
> >> to date  > anymore, of course. It sounds to me like you compare
> >> branches with per  > convention immutable tags to come to the
> >> conclusion that both have  > different semantics. But that's not the
> >> case, just a result of
> > your
> >>  > immutable tags convention.
> >>  >
> >>  >>  So I silently
> >>  >>  miss the fact that the latest code changes I wanted to pull in
> > are
> >>  >> over on trunk, not on this tag I checked out from.
> >>  >
> >>  > Because with checking out a tag and keeping it immutable you want
> >> that  > tag and not trunk. Or what's the reason for checking out that
> > special
> >>  > tag at all? Especially if you know it's immutable, if it
> > wouldn't be
> >>  > immutable you of course would get new commits.
> >>
> >>  I think he's thinking of CVS style tags, which are mutable in that
> >> you  can modify which version of different files have the tag. So
> >> everyone  works on HEAD and a "STABLE" tag progresses across it as
> > developers
> >>  decide different ports are stable.
> >
> > My example was a poor choice, as I prefer non-mutable tags, but there
> > are certainly use-cases for mutable and non-mutable. There are
> > certainly examples from other versioning tools. "Baselines" concept in
> > ClearCase, that can be defined then locked. But those get too complex
> > very fast. I really prefer the kind of simplicity in Svn.
> >
> >>
> >>  However, as you've mentioned and was more at length discusses
> >> elsewhere  that's simply not have SVN works.
> >
> > Agreed. I understand how Svn works, and it's fine how it works. But
> > I'm arguing that I'd like to see an additional type of object that
> > would be useful...
> 
> One way to do that would be to have another directory that you have the
> hook scripts configured to make read-only.
> So:
> 
> /trunk
> /branches
> /tags
> /tags-readOnly
> 
> Again, you're going to a hook-script to do it as that is how SVN
> enforces it best.
> Yes, there is the permissions structure but there's no easy way to do a
> globular matching like the following:
> 
> [/*readOnly*]
> @users = r
> 
> That is certainly one feature that would be very handy if ever
> implemented.
> 
> >>  A similar kind of workflow for SVN would be:
> >>  Main work: /trunk
> >>  Trunk Stable "tag" or branch: /tags/trunk-stable or
> > /branches/trunk-
> >>  stable
> >>
> >>  Do work in /trunk, as things are declared "stable" merge to
> >> /branches/trunk-stable.
> >>
> >>  While I have in the past been able to sympathize with people looking
> >> for  CVS-style tags (and still do to some extent), I think Subversion
> >> style  Tags are far more superior primarily from the fact that you
> >> can track  any