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
Guten Tag jane34,
am Samstag, 15. Oktober 2011 um 17:24 schrieben Sie:
> Then I recreate the new file trunk/dir/source.file and commited it again in
> revision 10
This was the error, you should have reverted revision 7 where you
deleted.
http://subversion.apache.org/faq.html#undo
http://svnbook.
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
Hi everybody!
I have deleted some file from SVN repository, saying trunk/dir/source.file ,
I have erased it with whole directory "dir" and commited it. That was in
revision 7.
Then I recreate the new file trunk/dir/source.file and commited it again in
revision 10, but the history of that new fil
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:/
Hi everyone,
here is an issue I encountered with svn client 1.7.0
We at work are currently working with server/client 1.6.5 on Fedora 10
I tried svn client 1.7.0 and immediatly run into following erroneous behaviour.
Easy to reproduce.
Let's say we have a working copy of 'A' set up using svn
14 matches
Mail list logo
