You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bill Williams <bi...@qcsoftware.com> on 2006/03/28 19:03:03 UTC
SVN status indicating a file is modified when it's not.
I think maybe I've found a bug with the windows version of subversion.
We are using SVN 1.3.0 with svnserve giving us access to the repository.
We have a mixed environment. Our server is linux and our workstations
are windows accessing the linux server via samba. When I first created
the various workspaces, I checked everything out under linux. All
source code files and makefiles have the eol-style set to native;
therefore, all of files are in unix format with the lines ended with a
newline character.
Since the initial checkout, changes have been made to both source code
and makefiles. These changes are usually performed under windows and
committed to the repository via Tortoise.
I will then update my particular workspace using Tortoise and this is
where the problem now appears. Under linux, an "svn status" command
shows no modifications which is correct. But under Windows, it will say
the makefile has been modified. It does this with both the "svn status"
command and Tortoise. I looked at the files that were changed and I
have found the newly updated source files and makefiles are now in a DOS
format with CR/LF on the end of the lines; however, the base files in
the .svn/text-base directory are all still in a unix format. What I
find interesting here is the source files do not show that they have
been modified, only the makefiles when this occurs.
Has anyone seen this behavior before?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN status indicating a file is modified when it's not.
Posted by Andy Levy <an...@gmail.com>.
On 3/29/06, Bill Williams <bi...@qcsoftware.com> wrote:
> Thanks for the suggestion. Since we are talking about hundreds of
> source code files, is there an easy way to set the property without
> doing it one file at a time.
On the Windows side, you can use TortoiseSVN to change properties on
multiple files at once. If you have a whole directory (and
subdirectories), it can be told to recurse through all that as well.
There are other ways as well, I've just found that this has been the
most expedient for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN status indicating a file is modified when it's not.
Posted by Bill Williams <bi...@qcsoftware.com>.
Thanks for the suggestion. Since we are talking about hundreds of
source code files, is there an easy way to set the property without
doing it one file at a time.
Also, just to mention another odd thing about this. If I make a change
to the makefile and commit it on windows myself, "svn status" does not
show the file is modified after the commit even though it is still the
situation where the file itself if in DOS format while the text-base
file is in unix format. It only seems to be a problem when files are
updated via the "svn update" command.
Ryan Schmidt wrote:
> On Mar 28, 2006, at 21:03, Bill Williams wrote:
>
>> We have a mixed environment. Our server is linux and our
>> workstations are windows accessing the linux server via samba. When
>> I first created the various workspaces, I checked everything out
>> under linux. All source code files and makefiles have the eol- style
>> set to native; therefore, all of files are in unix format with the
>> lines ended with a newline character.
>>
>> Since the initial checkout, changes have been made to both source
>> code and makefiles. These changes are usually performed under
>> windows and committed to the repository via Tortoise.
>>
>> I will then update my particular workspace using Tortoise and this
>> is where the problem now appears. Under linux, an "svn status"
>> command shows no modifications which is correct. But under Windows,
>> it will say the makefile has been modified. It does this with both
>> the "svn status" command and Tortoise. I looked at the files that
>> were changed and I have found the newly updated source files and
>> makefiles are now in a DOS format with CR/LF on the end of the
>> lines; however, the base files in the .svn/text-base directory are
>> all still in a unix format. What I find interesting here is the
>> source files do not show that they have been modified, only the
>> makefiles when this occurs.
>
>
> I think if you're going to have a working copy that's used both from
> Windows and from Unix then you shouldn't use svn:eol-style=native
> because it'll just confuse Subversion, as you're seeing. I'd set
> svn:eol-style to either DOS-style or Unix-style line endings,
> whatever you need, and then ensure that your editors on both Unix and
> Windows use this line ending style.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN status indicating a file is modified when it's not.
Posted by Bill Williams <bi...@qcsoftware.com>.
I have been doing some additional investigating. It now appears it must
be something to do with samba. I copied my workspace from the samba
share onto my windows computer's local disk and when I went to the same
directory that showed the makefile was modified on the samba share, it
shows everything is not modified on my computer's local disk. I checked
and the same situation exists on my local disk where the text-base file
is unix format and the normal file is dos format.
I even went back to the samba share and made the files have the same
format (tried both dos and unix) and svn status still says the makefile
was modified. What really makes this bizarre is this only occurs with
makefiles. My other source code status is reported properly. It also
only occurs if I had to update by workspace because someone else made a
change. If I make the change and commit it, the problem does not occur
even though the file formats are the same (text-base is unix and normal
file is dos format) as when I do the update.
Does anyone else use samba as a server to their windows computer and
have they seen anything remotely like this? Next I'm going to post a
message on the samba mail list to see what they say.
Ryan Schmidt wrote:
> On Mar 28, 2006, at 21:03, Bill Williams wrote:
>
>> We have a mixed environment. Our server is linux and our
>> workstations are windows accessing the linux server via samba. When
>> I first created the various workspaces, I checked everything out
>> under linux. All source code files and makefiles have the eol- style
>> set to native; therefore, all of files are in unix format with the
>> lines ended with a newline character.
>>
>> Since the initial checkout, changes have been made to both source
>> code and makefiles. These changes are usually performed under
>> windows and committed to the repository via Tortoise.
>>
>> I will then update my particular workspace using Tortoise and this
>> is where the problem now appears. Under linux, an "svn status"
>> command shows no modifications which is correct. But under Windows,
>> it will say the makefile has been modified. It does this with both
>> the "svn status" command and Tortoise. I looked at the files that
>> were changed and I have found the newly updated source files and
>> makefiles are now in a DOS format with CR/LF on the end of the
>> lines; however, the base files in the .svn/text-base directory are
>> all still in a unix format. What I find interesting here is the
>> source files do not show that they have been modified, only the
>> makefiles when this occurs.
>
>
> I think if you're going to have a working copy that's used both from
> Windows and from Unix then you shouldn't use svn:eol-style=native
> because it'll just confuse Subversion, as you're seeing. I'd set
> svn:eol-style to either DOS-style or Unix-style line endings,
> whatever you need, and then ensure that your editors on both Unix and
> Windows use this line ending style.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: SVN status indicating a file is modified when it's not.
Posted by Wayne J <wa...@zk.com>.
>If that's the point, then fine, do that, but then you must check out
>and manipulate the working copy exclusively from windows. It's only
>"native" to the OS doing the Subversion manipulation. So if you check
>out on Unix, you get Unix linefeeds. If you then try to edit that
>working copy on Windows, the linefeeds are Unix-native, not Windows-
>native. Hence the problem.
I missed the part in the original post where the working copy was on a
Linux drive and accessed from Windows via Samba.
The other solution is to only access the repository using the Windows
svn client or the Linux client. It seems to me it would be safer to use
native EOLS and not mix the clients. One of my co-workers uses Cygwin to
do a lot of stuff. I am not sure exactly what he does but he I end up
getting documents from him where the he has generated files using Cygwin
+ Windows tools that have weird EOLs, lines with both Unix and Windows
EOLS at the end ...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN status indicating a file is modified when it's not.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 29, 2006, at 18:13, Wayne J wrote:
>> I think if you're going to have a working copy that's used both from
>> Windows and from Unix then you shouldn't use svn:eol-style=native
>> because it'll just confuse Subversion, as you're seeing. I'd set
>> svn:eol-style to either DOS-style or Unix-style line endings,
>> whatever you need, and then ensure that your editors on both Unix and
>> Windows use this line ending style.
>
> Isn't this the whole point of having the svn:eol-style = native?
>
> Some windows applications simply do not handle Unix style EOLs well at
> all.
If that's the point, then fine, do that, but then you must check out
and manipulate the working copy exclusively from windows. It's only
"native" to the OS doing the Subversion manipulation. So if you check
out on Unix, you get Unix linefeeds. If you then try to edit that
working copy on Windows, the linefeeds are Unix-native, not Windows-
native. Hence the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: SVN status indicating a file is modified when it's not.
Posted by Wayne J <wa...@zk.com>.
>I think if you're going to have a working copy that's used both from
>Windows and from Unix then you shouldn't use svn:eol-style=native
>because it'll just confuse Subversion, as you're seeing. I'd set
>svn:eol-style to either DOS-style or Unix-style line endings,
>whatever you need, and then ensure that your editors on both Unix and
>Windows use this line ending style.
Isn't this the whole point of having the svn:eol-style = native?
Some windows applications simply do not handle Unix style EOLs well at
all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN status indicating a file is modified when it's not.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 28, 2006, at 21:03, Bill Williams wrote:
> We have a mixed environment. Our server is linux and our
> workstations are windows accessing the linux server via samba.
> When I first created the various workspaces, I checked everything
> out under linux. All source code files and makefiles have the eol-
> style set to native; therefore, all of files are in unix format
> with the lines ended with a newline character.
>
> Since the initial checkout, changes have been made to both source
> code and makefiles. These changes are usually performed under
> windows and committed to the repository via Tortoise.
>
> I will then update my particular workspace using Tortoise and this
> is where the problem now appears. Under linux, an "svn status"
> command shows no modifications which is correct. But under
> Windows, it will say the makefile has been modified. It does this
> with both the "svn status" command and Tortoise. I looked at the
> files that were changed and I have found the newly updated source
> files and makefiles are now in a DOS format with CR/LF on the end
> of the lines; however, the base files in the .svn/text-base
> directory are all still in a unix format. What I find interesting
> here is the source files do not show that they have been modified,
> only the makefiles when this occurs.
I think if you're going to have a working copy that's used both from
Windows and from Unix then you shouldn't use svn:eol-style=native
because it'll just confuse Subversion, as you're seeing. I'd set
svn:eol-style to either DOS-style or Unix-style line endings,
whatever you need, and then ensure that your editors on both Unix and
Windows use this line ending style.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org