info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Visual Studio .NET projects and CVS


From: Mike Ayers
Subject: Re: Visual Studio .NET projects and CVS
Date: Mon, 28 Oct 2002 14:28:47 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

Kaz Kylheku wrote:

Knowing what files are primary objects that should be version
controlled is a Visual .NET problem, not a CVS problem. It's your
responsibility to understand the development tool you are using,
and know what all the .dsw, .opt, .ncb, .aps and whatever files mean.

So that means no asking for help? Sheesh! If you want to just jump somebody's case, do it for something legitimate, like sending HTML email to a mailing list.

I have successfully rebuilt "Visual" projects with nothing more than a *.dsp or *.dsw file, as of Visual Studio 6, but have not tried with .NET. I have also archived all the files, and that worked fine, too.

My general rules for archiving projects from development environments that produce mystery files:

1) Examine each file with a text editor. Do NOT use a text editor that autosaves to the original file. Do NOT use a text editor that cannot handle binary data. I use emacs and never have a problem. It should be immediately obvious if this is a binary file. If so, add it as binary.

2) Add the remaining files as text individually. If CVS feels that the file may be binary, abort the add and add it as Unicode. This is especially relevant for Microsoft-on-Microsoft development systems such as the "Visual" line.

3) If you are working in a read-only-by-default configuration, do `cvs edit` on all such files.

4) Just do your work as usual, and check in all the changed files as updates before doing any reference tags.


        This methodology has a few niceties:

        1)  You need know nothing about which files are what.

2) If you need to go back to a certain tag, your development environment will go back with you (sometimes this may not be so good).

3) You can highly customize the development environment, using branches to develop features, and get the customizations for each branch.

Of course, you need to trade off the value to your team of these niceties with the cost of archiving them before deciding which you would like to do.


        HTH,

/|/|ike






reply via email to

[Prev in Thread] Current Thread [Next in Thread]