Translation status report for trunk@r1238144
lang trans untrans fuzzy obs
--
de2082 190 308 270 UUooo
es2008 264 385 404 ++UUU~
fr2270 2
On 31.01.2012 02:47, Bert Huijben wrote:
> Last time we discussed this in depth (a few years ago), Windows didn't
> perform the normalization you describe here.
> Was this added later? (Any documentation pointers?)
Ouch, you're right ... Windows API doesn't normalize the paths.
-- Brane
> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu]
> Sent: maandag 30 januari 2012 16:11
> To: dev@subversion.apache.org
> Subject: Re: Let's discuss about unicode compositions for filenames!
>
> On 31.01.2012 00:14, Peter Samuelson wrote:
> > [Stefan Sperling]
> >> It is in
On 30.01.2012 22:19, Stefan Sperling wrote:
> On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote:
>> No, AFAIU, Brane's suggestion was not that we shouldn't use the
>> "reintegrate-way" for 3.2, but rather that we should *always* use the
>> "reintegrate-way", also for sync merges. So t
On 31.01.2012 00:14, Peter Samuelson wrote:
> [Stefan Sperling]
>> It is indeed harder because we are passing paths verbatim to sqlite.
>> I doubt having more than one form of a given path in wc.db is fun...
> That's the implementation I would like to see, to be honest. Start
> with the observatio
[Stefan Sperling]
> It is indeed harder because we are passing paths verbatim to sqlite.
> I doubt having more than one form of a given path in wc.db is fun...
That's the implementation I would like to see, to be honest. Start
with the observation that we can treat Mac OS X NFD paths as a client
On Mon, Jan 30, 2012 at 11:16 PM, Stefan Sperling wrote:
> On Mon, Jan 30, 2012 at 10:37:51PM +0100, Johan Corveleyn wrote:
>> On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling wrote:
>> > But you cannot use the last-synced revision as left anchor either:
>> > svn co b
>> > svn merge b@r4 a@r6
On Mon, Jan 30, 2012 at 10:37:51PM +0100, Johan Corveleyn wrote:
> On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling wrote:
> > But you cannot use the last-synced revision as left anchor either:
> > svn co b
> > svn merge b@r4 a@r6 b
> > Because applying this delta reverts b@r5 (this change appe
On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling wrote:
> On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote:
>> No, AFAIU, Brane's suggestion was not that we shouldn't use the
>> "reintegrate-way" for 3.2, but rather that we should *always* use the
>> "reintegrate-way", also for syn
On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote:
> No, AFAIU, Brane's suggestion was not that we shouldn't use the
> "reintegrate-way" for 3.2, but rather that we should *always* use the
> "reintegrate-way", also for sync merges. So that a sync merge picks
> its arguments for the 2-
On Mon, Jan 30, 2012 at 2:23 PM, Stefan Sperling wrote:
> On Tue, Jan 24, 2012 at 01:12:39AM +0100, Branko Čibej wrote:
>> By the way, I read Stefan's description of why --reintegrate is
>> necessary, and after slogging through the unfortunate terminology (2-URL
>> merge doesn't mean a thing in CM
On Mon, Jan 30, 2012 at 09:34:03PM +0100, Branko Čibej wrote:
> Sure, if you want to turn on such normalization, you pretty much have to
> dump and reload the repository as well as upgrading all working copies
> (again). Either that, or use form-independent comparison on the server,
> which isn't s
On 30.01.2012 21:29, Stefan Sperling wrote:
> On Mon, Jan 30, 2012 at 09:09:22PM +0100, Branko Čibej wrote:
>> Are you seriously proposing that we /support/ such broken, hackish
>> nonsense? How do you expect users to tell the difference between file
>> names that look identical on the character le
On Mon, Jan 30, 2012 at 09:09:22PM +0100, Branko Čibej wrote:
> Are you seriously proposing that we /support/ such broken, hackish
> nonsense? How do you expect users to tell the difference between file
> names that look identical on the character level, but are not on the
> code point level?
>
> S
On Mon, Jan 30, 2012 at 9:09 PM, Branko Čibej wrote:
> On 30.01.2012 21:00, Johan Corveleyn wrote:
>> On Mon, Jan 30, 2012 at 8:10 PM, Stefan Sperling wrote:
>>> On Tue, Jan 31, 2012 at 01:42:21AM +0900, Hiroaki Nakamura wrote:
2012/1/30 Stefan Sperling :
>> [ ... ]
>>
>>> And mixing various
On 30.01.2012 21:00, Johan Corveleyn wrote:
> On Mon, Jan 30, 2012 at 8:10 PM, Stefan Sperling wrote:
>> On Tue, Jan 31, 2012 at 01:42:21AM +0900, Hiroaki Nakamura wrote:
>>> 2012/1/30 Stefan Sperling :
> [ ... ]
>
>> And mixing various unicode forms works fine today if the filesystem
>> used by t
On Mon, Jan 30, 2012 at 8:10 PM, Stefan Sperling wrote:
> On Tue, Jan 31, 2012 at 01:42:21AM +0900, Hiroaki Nakamura wrote:
>> 2012/1/30 Stefan Sperling :
[ ... ]
> And mixing various unicode forms works fine today if the filesystem
> used by the client supports this. The use case Neels contrive
On Tue, Jan 31, 2012 at 01:42:21AM +0900, Hiroaki Nakamura wrote:
> 2012/1/30 Stefan Sperling :
> > My friend is not willing to upgrade to a new client version yet, which
> > is fine because all 1.x releases of Subversion clients are supposed
> > to be compatible with all 1.y releases of Subversion
Paul Burba wrote:
> Julian Foad wrote:
>> [...] The way I read the proposed 'server-dictated config' scheme,
>> it didn't include a way to configure different values for
>> 'global-ignores' to apply to different directories inside the WC,
>> [...]
>
> That is incorrect, the server dictated con
On 01/27/2012 02:10 AM, vijay wrote:
> Fix the helper function 'change_rev_prop' to use functions which perform
> validation of the property value if 'validate_props' is set. Otherwise,
> bypass those checks.
>
> * subversion/libsvn_repos/load-fs-vtable.c
> (change_rev_prop): Do the property val
On Mon, Jan 30, 2012 at 11:05 AM, Julian Foad
wrote:
> Branko Čibej wrote:
>
>> On 27.01.2012 12:53, Julian Foad wrote:
>>> Branko Čibej wrote:
On 27.01.2012 11:50, Julian Foad wrote:
> We need to see how we'd implement a reasonable system of svn:ignores
> and auto-props using th
On 30.01.2012 17:05, Julian Foad wrote:
> No. The way I read the proposed 'server-dictated config' scheme, it didn't
> include a way to configure different values for 'global-ignores' to apply to
> different
> directories inside the WC, only for transmitting a single value of
> 'global-ignore
Garret Wilson wrote on Mon, Jan 30, 2012 at 06:31:19 -0800:
> On 1/29/2012 11:26 PM, Daniel Shahaf wrote:
> >...
> >
> >- Publish your "properties migration" code for others to reuse.
>
> Done:
>
> https://...
Thanks.
> >[1] If you answer "In a specification" I'll ask how it would relate to
> >
On 01/30/2012 02:00 PM, Markus Schaber wrote:
> Maybe the best solution to this issue is a client-only solution, in a similar
> way the case sensitivity problem is tackled.
Spinning the client-only thought a bit: Imagine a repos with a un*x user
adding a file called "föö". Now an OSX user checks
Let me just note some of the main similarities and differences between this
issue of Unicode compositions and the issue of case-sensitivity in file names.
Differences:
* NFC and NFD look the same when
displayed, and most users haven't heard of them and don't expect that a
computer might treat
Hi, Peter,
Von: Peter Samuelson [mailto:pe...@p12n.org]
>> [Stefan Sperling]
>> > We could also open the parent directory, read all the filenames
>> > within it, normalise them all, and then search the resulting list.
>> > This works, expect if a name exists twice, once in NFC form and once
>>
Branko Čibej wrote:
> On 27.01.2012 12:53, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 27.01.2012 11:50, Julian Foad wrote:
We need to see how we'd implement a reasonable system of svn:ignores
and auto-props using the proposed inheritable properties system. The
ability
Running with this patch:
[[[
% $svn diff -x-p
Index: subversion/mod_dav_svn/liveprops.c
===
--- subversion/mod_dav_svn/liveprops.c (revision 1237720)
+++ subversion/mod_dav_svn/liveprops.c (working copy)
@@ -721,6 +721,7 @@ insert_pr
On Mon, Jan 30, 2012 at 10:01:23AM -0500, Mark Mielke wrote:
> No merge is perfect. The situation is either complex, or it is not
> complex - and moving resolution to the private branch is a matter of
> process - not a matter of algorithm.
Where did you get the idea that conflict resolution must h
[Stefan Sperling]
> > We could also open the parent directory, read all the filenames
> > within it, normalise them all, and then search the resulting
> > list. This works, expect if a name exists twice, once in NFC form
> > and once in NFD form. We'd somehow have to solve the name collision
> >
On 01/29/2012 02:14 PM, Garret Wilson wrote:
> On 1/29/2012 10:55 AM, Branko Čibej wrote:
>> ... I can't help wondering why you didn't ask about valid property names
>> /before/ you created a bunch of invalid ones. Sounds like you made one too
>> many assumption.
>
> Wait, seriously? You're sayin
Stefan: I believe you are agreeing that the merge in either direction is
the same complexity, and describing how --reintegrate moves the
responsibility for the complexity to the owner of the private branch,
and requires resolution before submission. I think you are saying this
is a good thing b
On Mon, Jan 30, 2012 at 06:31:19AM -0800, Garret Wilson wrote:
> Think about it in terms of XML: There is a specification for the XML
> API, the DOM: http://www.w3.org/TR/DOM-Level-3-Core/core.html .
> However, the API specification still depends on the definition of
> what XML itself is (e.g. what
On 01/27/2012 04:38 PM, Paul Burba wrote:
> Now let's say we implement inheritable properties as I described in
> the wiki and want to use an inheritable property to supplement the
> existing mechanisms for svn:ignores/global-ignores. Isn't that as
> simple as this?
>
> 4) We add a new reserved i
On 1/29/2012 11:26 PM, Daniel Shahaf wrote:
...
- Publish your "properties migration" code for others to reuse.
Done:
https://svn.globalmentor.com/java/trunk/globalmentor-marmot/src/main/java/com/globalmentor/marmot/repository/svn/svnkit/SVNKitSubversionRepository.java
You'll need the relate
On Mon, Jan 30, 2012 at 02:23:46PM +0100, Stefan Sperling wrote:
> What we use during --reintegrate is (3.2 b).
And here I'm catching myself spreading misinformation again.
There is another tweak we use during reintegrate.
Consider the graph again (fixed version):
(3)
+-b@
On Mon, Jan 30, 2012 at 02:23:46PM +0100, Stefan Sperling wrote:
> (3)
> +-b@r2--+ b@r3--b@r4-b@r5
> (branch) /^ | (merge 2)
> / | (merge 1) v
> --- a@r1 --a@r2---+- a@r6
>
> Merge 1 brings a@r2 in
On Tue, Jan 24, 2012 at 01:12:39AM +0100, Branko Čibej wrote:
> By the way, I read Stefan's description of why --reintegrate is
> necessary, and after slogging through the unfortunate terminology (2-URL
> merge doesn't mean a thing in CM theory :) and one little bit caught my
> attention:
>
> > A
Hi,
Von: Stefan Sperling [mailto:s...@elego.de]
> On Sun, Jan 29, 2012 at 07:38:44PM +0900, Hiroaki Nakamura wrote:
>> I read the note about unicode compositions for filenames
>> http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames
>> and would like to drive
Philip Martin writes:
> Branko Čibej writes:
>
>> On 30.01.2012 11:14, Philip Martin wrote:
>>> - the backend FS layer allows any null terminated string as a property
>>>name
>>>
>>> - the frontend client layer restricts property names to a subset of
>>>ASCII
>>
>> And the HTTP layer h
On 30.01.2012 13:30, Stefan Sperling wrote:
> On Sun, Jan 29, 2012 at 07:38:44PM +0900, Hiroaki Nakamura wrote:
>> Hi folks!
>>
>> I read the note about unicode compositions for filenames
>> http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames
>> and would like t
On Sun, Jan 29, 2012 at 07:38:44PM +0900, Hiroaki Nakamura wrote:
> Hi folks!
>
> I read the note about unicode compositions for filenames
> http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames
> and would like to drive the discussion.
Hi,
I am very happy to h
On 30.01.2012 12:06, Philip Martin wrote:
> Philip Martin writes:
>
>> Branko Čibej writes:
>>
>>> On 30.01.2012 11:14, Philip Martin wrote:
- the backend FS layer allows any null terminated string as a property
name
- the frontend client layer restricts property names to
Philip Martin writes:
> Branko Čibej writes:
>
>> On 30.01.2012 11:14, Philip Martin wrote:
>>> - the backend FS layer allows any null terminated string as a property
>>>name
>>>
>>> - the frontend client layer restricts property names to a subset of
>>>ASCII
>>
>> And the HTTP layer h
Branko Čibej writes:
> On 30.01.2012 11:14, Philip Martin wrote:
>> - the backend FS layer allows any null terminated string as a property
>>name
>>
>> - the frontend client layer restricts property names to a subset of
>>ASCII
>
> And the HTTP layer has its own implicit restrictions.
On 30.01.2012 11:14, Philip Martin wrote:
> Daniel Shahaf writes:
>
>> - Send a patch to svn_repos__validate_props() (and make your case that
>> it should be applied)
> I think the current situation for property names is:
>
> - the backend FS layer allows any null terminated string as a propert
Daniel Shahaf writes:
> - Send a patch to svn_repos__validate_props() (and make your case that
> it should be applied)
I think the current situation for property names is:
- the backend FS layer allows any null terminated string as a property
name
- the frontend client layer restricts p
47 matches
Mail list logo
