On Sat, Oct 15, 2011 at 2:18 AM, Ryan Schmidt
wrote:
> On Oct 14, 2011, at 18:52, Johan Corveleyn wrote:
>> Ah, but git-svn doesn't seem to honor the invariant that files with
>> native eol-style *must* be converted to LF by the client. By not doing
>> this, they break things for every other svn c
So just forbid svn:eol-style in your repositories and you'll have the
model you want.
On Sun, Oct 16, 2011 at 12:36 AM, Nico Kadel-Garcia wrote:
> On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell wrote:
>> On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia wrote:
>>>
>>> Perhaps a better approach, especially if you know people will be using
>>> git-svn, is to review the repository
On Sat, Oct 15, 2011 at 5:36 PM, Nico Kadel-Garcia wrote:
>
> The git model for EOL is safer, to my mind, because it is
> *predictable*.
Yes, but predictably not working isn't very useful.
--
Les Mikesell
lesmikes...@gmail.com
On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell wrote:
> On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia wrote:
>>
>> Perhaps a better approach, especially if you know people will be using
>> git-svn, is to review the repository for any files that use svn:eol,
>> and *turn that off*, with a che
On Sat, 15 Oct 2011 10:41:57 +, Les Mikesell wrote:
...
> But a binary EOL is almost never works for cross platfom text. Which
> is why systems designed for cross platform work do the conversions.
> How do git users deal with it?
Only relatively lately, by some local setting that actually doe
On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia wrote:
>
> Perhaps a better approach, especially if you know people will be using
> git-svn, is to review the repository for any files that use svn:eol,
> and *turn that off*, with a check that the binary EOL is the format
> you want. Then put in
On Sat, Oct 15, 2011 at 8:25 AM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Sat, Oct 15, 2011 at 01:52:32 +0200:
>> Thanks. Seems I can experiment a bit with that. Though I think the
>> problem is specific to eol-style=native (not any eol-style). I thought
>> that the "conversion-to-LF" only
Johan Corveleyn wrote on Sat, Oct 15, 2011 at 01:52:32 +0200:
> On Fri, Oct 14, 2011 at 4:56 PM, Daniel Shahaf
> wrote:
> > Johan Corveleyn wrote on Fri, Oct 14, 2011 at 16:25:46 +0200:
> >> You can identify the corrupt files easily by taking a look at the
> >> corresponding pristine files (or .s
Ryan Schmidt wrote on Fri, Oct 14, 2011 at 19:37:44 -0500:
> On Oct 14, 2011, at 19:30, Daniel Shahaf wrote:
> > Ryan Schmidt wrote on Fri, Oct 14, 2011 at 19:18:44 -0500:
> >> When svn:eol-style is set to ANY value, the file is stored in the
> >> repository with LF line endings, and converted to t
Konstantin Kolinko wrote on Sat, Oct 15, 2011 at 14:27:43 +0400:
> 2011/10/14 Daniel Shahaf :
> > for f in $CHANGED_FILES; do
> > if svnlook pl -t $txn $repos $f | grep -w svn:eol-style >/dev/null && [
> > "`svnlook cat -t $txn $repos $f | xxd -ps -c1 | fgrep 0d | head -n1`" ];
> > then
> >e
> Konstantin Kolinko wrote on Fri, Oct 14, 2011 at 17:43:03 +0400:
>> Hi!
>>
>> One of committers in Apache Tomcat project is experimenting with Git
>> <-> Subversion integration.
>>
>> A result is that in the last few days several commits produced diffs
>> for entire file. An example:
>>
>> http:/
On Oct 14, 2011, at 19:30, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Fri, Oct 14, 2011 at 19:18:44 -0500:
>> When svn:eol-style is set to ANY value, the file is stored in the
>> repository with LF line endings, and converted to the desired EOL
>> style by the client on checkout or export (and co
Ryan Schmidt wrote on Fri, Oct 14, 2011 at 19:18:44 -0500:
> When svn:eol-style is set to ANY value, the file is stored in the
> repository with LF line endings, and converted to the desired EOL
> style by the client on checkout or export (and converted by the client
> to LF line endings before bei
On Oct 14, 2011, at 18:52, Johan Corveleyn wrote:
> Ah, but git-svn doesn't seem to honor the invariant that files with
> native eol-style *must* be converted to LF by the client. By not doing
> this, they break things for every other svn client using the same
> repository. So this is clearly a bug
On Fri, Oct 14, 2011 at 4:56 PM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Fri, Oct 14, 2011 at 16:25:46 +0200:
>> These "modified" files can also cause tree conflicts (which can
>> generate quite some WTF's).
>>
>
> Tree conflicts? How? I'd have expected (full-file) text conflicts only.
Johan Corveleyn wrote on Fri, Oct 14, 2011 at 16:25:46 +0200:
> These "modified" files can also cause tree conflicts (which can
> generate quite some WTF's).
>
Tree conflicts? How? I'd have expected (full-file) text conflicts only.
> You can identify the corrupt files easily by taking a look a
On Fri, Oct 14, 2011 at 3:54 PM, Stefan Sperling wrote:
> On Fri, Oct 14, 2011 at 05:43:03PM +0400, Konstantin Kolinko wrote:
>> Hi!
>>
>> One of committers in Apache Tomcat project is experimenting with Git
>> <-> Subversion integration.
>>
>> A result is that in the last few days several commits
The file has CR's in r1183340 but not in r1183339. Yes, since it has
svn:eol-style set, it is supposed to be stored in LF on the server.
Konstantin Kolinko wrote on Fri, Oct 14, 2011 at 17:43:03 +0400:
> Hi!
>
> One of committers in Apache Tomcat project is experimenting with Git
> <-> Subversio
On Fri, Oct 14, 2011 at 05:43:03PM +0400, Konstantin Kolinko wrote:
> Hi!
>
> One of committers in Apache Tomcat project is experimenting with Git
> <-> Subversion integration.
>
> A result is that in the last few days several commits produced diffs
> for entire file. An example:
>
> http://svn.
Hi!
One of committers in Apache Tomcat project is experimenting with Git
<-> Subversion integration.
A result is that in the last few days several commits produced diffs
for entire file. An example:
http://svn.apache.org/viewvc?view=revision&revision=1183340
http://svn.apache.org/viewvc/tomcat/t
21 matches
Mail list logo
