Re: line endings in text files and -kb

[Ittay Dror]

Todd Denniston wrote:
> Ittay Dror wrote, On 09/11/2008 01:39 PM:
> > Todd Denniston wrote:
> > > Ittay Dror wrote, On 09/11/2008 12:14 PM:
> > > > Larry Jones wrote:
> > > > > Ittay Dror writes:
> <SNIP>
> > > On windows, are you using cvs under cygwin or CVSNT?
> > turtoise cvs
>
> which IIRC means you are using CVSNT as your client.
>
> <SNIP>
> > > windows programs interpret text files different than Unix programs 
> > > interpret text files, and cvs knows how and when to do the 
> > > translation of text files, that it has not been told are binary.  
> > > Usually folks WANT the translation, that is why good ftp clients let 
> > > you tell them you are transferring text files so that the client and 
> > > server can negotiate any needed translation.
> > ok, but in this case i'm not editing the file, i'm just moving it 
> > around to create a product tree. someone else edited it and committed 
> > and the build just so happens to run on windows. also, afaik, most 
> > windows ides (outside of notepad) know how to handle just \n today.
>
> Here is the clue...
> First rule of using any version control tool: DO NOT DO THINGS BEHIND 
> THE TOOL'S BACK!
first rule of any tool: do not take actions unless i request them. 
specifically, do not change a file unless i request to. and if changing 
a file is deemed as a reasonable default option, allow me to turn it off 
without any side effects (it being considered binary, no merge)
> "moving" a file around is almost always doing something behind the the 
> tool's back.
i'm moving it to an output directory outside of the cvs tree.
> if you want a file on a machine/in a tree, then check that file out of 
> CVS where you want it, and definitely don't put a moved file back into 
> CVS.
i didn't put it back
> when working on files, that you have an intention of committing back 
> into a version control system, changing a f
> * always do the checkouts so you get the sandbox you want.
> * always do the checkout on the OS you intend to work on.
> * do not contaminate the sandbox. (don't copy from other sandboxes, 
> don't update while having an editor's buffer open...)
> * let the version control tool manage the line endings.
> * bend and break these rules only with an understanding of the 
> implications, and the ability to be happy when you are left holding 
> the broken chunks.
>
> > > > >  
> > > > > > i don't. i want to prevent CVS from converting line endings. the 
> > > > > > file is
> > > > > > checked out in windows but is later used in linux (it is part of 
> > > > > > a product
> > > > > > build), but because CVS converts line endings, i get a 
> > > > > > '/bin/bash^M: bad
> > > > > > interpreter error'
> > > > > >     
> > > > >
> > > > > That's not CVS's fault.  If you want to use the file on Linux, you
> > > > >   
> > > > oh, it is, because cvs decided to change the file without giving me 
> > > > a reasonable way to tell it not to.
> > >
> > > Quite the opposite, YOU told cvs (via -kb) not to change the file, 
> > > and it obeyed, i.e., you added the file with -kb and then committed 
> > > it from MS, and on MS the file contained "/bin/bash^M", and because 
> > > of the -kb, cvs on Linux gave you EXACTLY the file committed on the 
> > > MS machine which contains "/bin/bash^M"
> > what happened is this:
> > - there was no -kb
> > - a developer checks out the source tree and works with it, making 
> > some changes to .c files
> >  - not touching the file in question. the file is a startup script 
> > for a daemon
> > - the build is ok on windows, so now he wants to check it is ok on linux
> >   - we don't want him to commit in order to test.
>
> OK, IMHO you have a problem in your process(es).
> Either you should have had the developer work on his/her own branch, 
> so they could keep their tested state under control while not affecting
branching in cvs is not cheap  and merging is always not cheap. afaiu, 
you're suggesting that  for every bug fix the developer needs to wait 
several minutes while cvs tags all files (there are appx 30000 btw), 
then do the change, commit, test, then merge (another long process). 
appart from all the time spent waiting on cvs actions, how maintainable 
will the history become?
> anyone else's tree, or you should have helped the developer understand 
> that when cross mounting a directory that the developer had to be 
> extremely mindful of the network file-system's propensity to carry 
> line ending translations.
??
I am developing a tool (a binary) that can work both under windows and 
linux. it requires wrapper scripts (and don't go now telling me i should 
write my scripts logic inside the tool. scripts exist for a reaon). so 
on windows they are .bat and on linux they are .sh. naturally i keep 
them in cvs. now i check out on my desktop, make a change to some .c 
file and want test on both my desktop and the linux machine before 
committing.
> in other words, if you are not an anal file-transport expert, then 
> don't do that.  Use cvs instead.
>
> > - so, he mounts the source tree from a linux machine and runs the build
> >  - this copies the file to the output of the build
> > - he wants to test the daemon, so he runs the startup script (the 
> > file in question)
> > --> this fails. the file was checked out in windows, so now it has ^M
> >
> > there is now the option to mark the file with -kb, thus solving the 
> > issue above, but merging will not work
> > >
> <SNIP>
> IMHO, bad technical solution to a process failure, because the 
> solution will in the end cause more problems of the type you are now 
> dealing with.
> I suggest: Change the process to allow/suggest/direct the developer to 
> make/use his|her own branch when they need to work on both OS's and 
> are currently not allowed, by process, to commit to the trunk|main 
> branch.
so they have to work in branches, either creating ones per change or 
constantly merging ongoing branches (and we know how well cvs is here) 
and all of this because cvs decided to change a file for me??? and if i 
want to tell it not to it suddenly decides the file is binary?? yep, 
sounds reasonable.
> I have had to do this, make my own side branch, myself several times 
> recently because I was doing development and the rest of the project 
> was making a release/test event.  Word of warning: branch the WHOLE 
> repository, because if you don't you will likely regret it later.


> > yes, it is the developer's responsibility to commit after dos2unix. 
> > in any case, even if he forgets, it is easy to fix (checkout, remove, 
> > commit)
> <SNIP>
> Assuming all your files that are to be ran on Unix are in one part of 
> the tree, you could setup a commitinfo script to ERROR out if they 
> detect the dev forgetting, and go back to not using -kb.  And although 
> you can modify the file on it's way to the repository, you should 
> search the history of this list and find out that many of the folks 
> who did eventually cried about the chunks left in their hands.

--
--
Ittay Dror <address@hidden>