Sometimes files can't be merged by update command in WinCVS

When you imported the new project, did you remove the directory and then checkout the directory fresh?

When you put a new project in cvs, you rename your original folder "out of the way" so that the folder does not "exist" anymore. You then checkout the project into the normal name.

Unless you want it digging through all the debug info in your project, horribly slowing it down, you have to setup the cvsignore file.

How did you import the project?

----

I recommend using cvsnt and doing EVERYTHING at the command line. You have to. It is more work to use WinCVS than using pure cvs commands at the command line. I'm hoping WinCVS gives you a command line cvs...

I'll show example of putting a project directory under cvs. I'll assume the project name (folder name) is myproj. Here's roughly what you'd do at the command line:

  cd \code\myproj
  cvs import -m "Initial import" myproj start
  cd ..
  move myproj myproj_before_cvs
  cvs co myproj

This will recreate the myproj folder *from CVS*. That means you will get what "everyone else" will get assuming their sandbox starts blank. You MUST do this when starting a project from CVS. You can't cheat and just keep the source directory that you already have. Keep it, just rename the folder "out of the way". Then extract the project from CVS. This creates the necessary extra files used by cvs.

You then compare myproj and myproj_before_cvs and make sure no files were inadvertently corrupted due to line-ending conversion/corruption. Check your binary files.

Unfortunately, on Windows systems, with CRLF line endings, CVS likes to corrupt every binary file format, except the ones you force it to treat binary. That's why you run comparison software (like WinMerge) to bulk compare entire trees of files (compare your new sandbox with sandbox_before_cvs). You have to configure CVS to recognize YOUR binary formats. It starts blank in some setups, with a minimum default of *.o *.obj *.exe, etc... It doesn't know pdb ilk and all the other extensive debug info extensions. You never care about changes to those files. It's the source files you care about. So you configure CVS to ignore the output-file file-extensions.

In order to prevent major problems you have to make cvs ignore all the debug info extensions. That means you have to edit the configuration of cvs.

At the command line:

  cd \code
  cvs co CVSROOT
  cd CVSROOT
  echo.>cvsignore
  write cvsignore
  [paste the following text in the wordpad window that appears]
*.dll
*.aps
*.bsc
*.crap
*.dat
*.exp
*.enc
*.plg
*.idb
*.pdb
*.sbr
*.ilk
*.pch
*.ncb
*.opt
*.ti
*.res
*.zip
*.rar
*.pif
*.lnk
*.map
  [end of text to paste in the wordpad window. Save and close Wordpad.]

  [only do the following line once. May not be necessary with WinCVS]
  cvs add cvsignore

  cvs ci cvsignore
  write cvswrappers
  [paste the following text in the wordpad window that appears]
*.gif -k 'b'
*.bmp -k 'b'
*.ico -k 'b'
  [end of text to paste in the wordpad window. Save and close Wordpad.]
  cvs ci cvswrappers
  cd ..
  rd /s CVSROOT

----

Add the appropriate extensions to the cvsignore list. Thats the extensions for files that are not necessary on a clean check out. Ignore=Faster.
Add the appropriate extensions to the cvswrappers list. Thats the binary files for which you *do* want changes logged.

Which language are you using?

If you want I can give some more command line tips. All the day-to-day commands are really simple.

You have the command names mixed up. Why update a single file? Sounds like you meant checkin.

import:
 As far as I know, is only used to pull in a new project that cvs knows nothing about.

update:
 See if anyone ELSE has made changes, and update my sandbox accordingly.
 This also shows a nice clean list of changed filenames. So you can review your changes. Use it alone, like this "cvs update", with no name.

checkin [filename]:
 Merge my changes into the repository, respecting/preserving changes others may have made

checkout [filename]:
 Forget what I have. It's garbage. I wrecked it. Get the latest revision out of the repository.

diff -c [filename]:
 Show a "diff style" analysis of your changes.

You can use ci and co as shorthand for checkin and checkout

Thanks, adg.
I will check how somebody checked in the project and try to set up the command line environment.

But I am looking for an answer for my current specific problem:
I did 'cvs update filename' for test.
The update command should merge my sandbox file and the repositery file.
Then, I can work on the merged file with >>>>> and <<<<<.
And then, I can commit it, right?
I think CVS has the commit command instead of checkin command.

I've only used "commit" when CVS told me to (ie. after adding a new source file, removing a source file, that kind of thing). It is not a day-to-day command.

Issuing a "cvs add" prompts you with something along the lines of "file added. Use commit to finalize".

Use checkin.

Note that there is nothing "wrong" with WinCVS - it is a tool for intermediate-to-advanced cvs users. It is WAY too hard to use for a beginner.

Adg,

I don't think CVS has 'checkin' command.
And I have a book 'Essential CVS' from O'Reilly in 2003.
It doesn't say anything about checkin command.

How do you get conflict files? update command, right?
I can get conflict files by update command sometimes.
But some file can't be conflicted by update command.

The command is ci

ci means checkin. Sorry about that... :)

Yes, the update command looks for changes that OTHER people have made, and merges them into your sandbox. It does write anything to the repository. It also lists files that have been added, deleted, modified, etc.

BUT, if you changed something (in your sandbox) that someone else *also* changed, you will get a conflict, and it will annotate the copy in your sandbox for you to resolve.

Here is a scenario where you need update:

You check out a file on Monday.
Jack checks it out on Tuesday and rewrites the printing code.
You rewrite something else on Wednesday.
Jack checks his in on Thursday
You try to check yours in but there is a conflict
You issue a cvs update command, and his printing code changes are merged into your sandbox
You check it in successfully

Actually, I'm not sure if that scenario would trigger a conflict, but it illustrates how cvs update brings in other people's changes.

I've done quite a bit of searching for understandable CVS information. Here is one I found quite easy to follow. It walks you through some typical scenarios:

http://cvsbook.red-bean.com/cvsbook.html

I just noticed something that might be creating confusion. When I issue a "cvs help" it prints the following:

        add          Add a new file/directory to the repository
        admin        Administration front end for rcs
        annotate     Show last revision where each line was modified
        chacl        Change the Access Control List for a directory
        checkout     Checkout sources for editing
        chown        Change the owner of a directory
        commit       Check files into the repository
        diff         Show differences between revisions
        edit         Get ready to edit a watched file
        editors      See who is editing a watched file
        export       Export sources from CVS, similar to checkout
        history      Show repository access history
        import       Import sources into CVS, using vendor branches
        init         Create a CVS repository if it doesn't exist
        info         Display information about supported protocols
        log          Print out history information for files
        login        Prompt for password for authenticating server
        logout       Removes entry in .cvspass for remote repository
        ls           List files in the repository
        lsacl        List the directories Access Control List
        passwd       Set the user's password (Admin: Administer users)
        authserver   Authentication server mode
        rannotate    Show last revision where each line of module was modified
        rdiff        Create 'patch' format diffs between releases
        release      Indicate that a Module is no longer in use
        remove       Remove an entry from the repository
        rlog         Print out history information for a module
        rtag         Add a symbolic tag to a module
        server       Server mode
        status       Display status information on checked out files
        tag          Add a symbolic tag to checked out version of files
        unedit       Undo an edit command
        update       Bring work tree in sync with repository
        version      Show current CVS version(s)
        watch        Set watches
        watchers     See who is watching a file

You'll notice that it does not list the "checkin" command OR the "ci" command. That's quite strange because I use "ci" all the time! It must be the same as commit.

Sorry for any confusion this may have caused. :)

Does this answer your question?

http://www.loria.fr/~molli/cvs/doc/cvs_10.html#SEC80

Thanks, adg,

I may confused my changes with other ones' changes.
I close this thread with accepting adg's answer.