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
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:
Konstantin Kolinko wrote on Sat, Oct 15, 2011 at 14:27:43 +0400:
2011/10/14 Daniel Shahaf d...@daniel.shahaf.name:
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` ];
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 the
Johan Corveleyn wrote on Sat, Oct 15, 2011 at 01:52:32 +0200:
On Fri, Oct 14, 2011 at 4:56 PM, Daniel Shahaf d...@daniel.shahaf.name
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
On Sat, Oct 15, 2011 at 8:25 AM, Daniel Shahaf d...@daniel.shahaf.name 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
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 file
On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia nka...@gmail.com 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.
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
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 does
On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell lesmikes...@gmail.com wrote:
On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia nka...@gmail.com 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,
On Sat, Oct 15, 2011 at 5:36 PM, Nico Kadel-Garcia nka...@gmail.com 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 Sun, Oct 16, 2011 at 12:36 AM, Nico Kadel-Garcia nka...@gmail.com wrote:
On Sat, Oct 15, 2011 at 11:41 AM, Les Mikesell lesmikes...@gmail.com wrote:
On Sat, Oct 15, 2011 at 9:23 AM, Nico Kadel-Garcia nka...@gmail.com wrote:
Perhaps a better approach, especially if you know people will be
So just forbid svn:eol-style in your repositories and you'll have the
model you want.
14 matches
Mail list logo
