|
Gregory.Gadow wrote: I'm pretty sure you can add other versioning databases than just VSS.
If you want subversion integration in Visual Studio, AnkhSVN is one plugin that facilitates this. I personally preferred TortoiseSVN (which is an Explorer shell extension).
|
|
|
|
|
I have found VisualSVN Server (free) and AnkhSVN plugin (free) a good combination.
Free + Free = just how we like it......
Dave
Find Me On: Web| Facebook| Twitter| LinkedIn
CPRepWatcher now available as Packaged Chrome Extension, visit my articles for link.
|
|
|
|
|
This,
Ankh svn plugin for Visual Studio will handle everything for you, you just check out, commit, etc a solution and the plugin will handle everything for you.
|
|
|
|
|
He's using VS Express, plug-ins are not supported.
|
|
|
|
|
RapidSVN is a good simple rich client
ken@kasajian.com / www.kasajian.com
|
|
|
|
|
No need to filter out, you can put everything on the share directory! j/k :p
VisualSvn is great for that, it's a shame you can't use it.
In C#, you should ignore these (maybe VB.NET has more?)
- Solution.suo which contains "solution user options"
- Project/bin/ which contains your builds
- Project/obj/ which contains temporary files for your builds
Also, the typical SVN structure is to have your application files within the "trunk" sub directory. This is useful so you can have another root directory for documentation, installer files, etc. and so you can have branches and tags directories too.
On the other hand, I've just switched to "distributed version control", namely Mercurial with TortoiseHg and I strongly recommend everyione that they look into it. I won't try to sell it to you (it's free  ), but if you're changing for a version control system, it probably is the best time for you to evaluate it. Even if you don't go for it, it will help you understand the version control concept in general. And there are many advantages to Mercurial like local commits/branches and a "real" tag feature.
Here's an article I read recently (thanks to the CodeProject daily newsletter) about structuring a Git repository (it's the same as Mercurial, but it was designed by some operating system inventor or whatever  ) : http://nvie.com/posts/a-successful-git-branching-model/?[^]
|
|
|
|
|
- Project/bin/ which contains your builds
What is the general / advised approach when developing reusable components for later inclusion via SVN externals?
Currently we have, e.g.
Component x - reusable component
Application 1 - application that uses component x
Application 2 - application that uses component x
In order to get applications 1 & 2 to use component x, we include the bin\* directories in SVN and refer to them in the applications as SVN externals pointing at the bin directories.
I'm guessing from the "don't include bin" suggestion that there's a better way of doing this - any suggestions? Bearing in mind that we don't want the applications to recompile the component each time.
|
|
|
|
|
We have a folder called 'Assemblies', into which we copy the generated .dlls when they are ready for consumption. This allows us to make changes (and check them in, so we don't lose our work) without affecting the 'upstream' items. When it is ready for a new 'release', copy the completed bin files into the Assemblies folder.
Then, the upstream projects have a References folder, with an entry for each 'subsystem' that needs to be referenced which points to the Assemblies folder for the subsystem.
Bin is not stored in our source control.
(we are using TortoiseSVN)
|
|
|
|
|
I use references and set their property to "copy local" or something like that. You can reference other projects so the dll is rebuilt and imported automatically to your build directory.
For asp.net, I guess you could use the strategy of having an "assemblies" directory and set their build action to "copy to output directory", and "copy if newer". If that is not available in asp.net, you could use a post build script to copy the files from assemblies to bin. And if all else fails, I think it's possible to declare that directory as a dll search path or something in the config, but that's less than ideal because it breaks the "standard" directory structure of an asp.net site...
|
|
|
|
|
Hi
I would say, preferably the files that doesn't change everytime you re-run an unmodified program.
e.g. not files that gets generated by the compiler each time you do a clean build.
Regards,
|
|
|
|
|
I agree with the other responses - ignore obj and bin folders and .suo and.user files.
I recommend Mercurial, also called Hg, as a good source control solution. It's dead simple. You can install TortoiseHg for GUI and the Explorer integration, and VisualHg for Visual Studio integration (including VS Express?). It can sync to your own hard drive, network drive, private web or ftp, or to a free account on BitBucket. Some say it is easier than Subversion and Git, both of which I've looked into but never used. We currently use Source Safe and I'm evaluating Mercurial and love it so far. But no doubt I would love a good tar and feathering than to continue to work with and trust Source Safe.
Do not use Source Safe. Almost anything is better. I read recently that Source Safe is the most dangerous software ever written that was not intentionally designed as a virus. Let's all have a moment of silence for Gregory.Gadow having to use it.
Mike
|
|
|
|
|
We use TSVN and VisualSVN. Here is my global ignore pattern, this will prevent listing folders or files when you add them to the repo:
*/bin */obj *.bak *.*scc *.user *.suo *.webinfo bin obj *.pdb *.exe *.DCS *.zip
2 years ago we moved from SoureSafe to SVN that is why I added to ingnore the .scc file.
|
|
|
|
|
As with so many things: it depends. If you are just doing hobby projects (which it sounds like you are) then excluding the output from compiles (the obj and bin folders) is absolutely fine.
However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control. The reasoning being that the state of the build machine can have an impact on the final deliverable ... add a patch and the compiler might produce something subtly different. It is also common under configuration management best practices to place documentation (program specs, user guides, operations manuals, etc) under version control too.
As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
|
|
|
|
|
Peter Trevor wrote: However, in a professional setting you may sometimes encounter a discipline called “configuration management”. (This is, essentially, management of the whole software lifecycle and integrates “change management”, “repository management”, “release management”, etc, into a coherent whole.) In configuration management it is common to include the final deliverables (*.exe, *.dll, etc) under version control.
However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract.
Consequently one would not check in source/proj/etc files at the same time as deliverables.
Peter Trevor wrote: As general advice I’d say, unless you are short of disk space, if in doubt add it in. Better to have an unnecessary file in the repository than to discover after the fact that you’ve lost the specific version of a key file.
Better to figure out what files are actually required. It becomes obvious with a clean extract.
|
|
|
|
|
jschell wrote: However one would then also expect that there would be a process step(s) which is specific to building as well. And it should start with a clean extract.Consequently one would not check in source/proj/etc files at the same time as deliverables.
Quite correct, sorry if that wasn’t clear. Overall in SCM (software configuration management) *final* deliverables are under version control but that does not mean that those deliverables are tracked in interim stages. (Depending on the specifics of the SCM plan being used ‘candidate’ final builds may also be version controlled.) As you point out, candidate final deliverables are usually built from a clean extract (and usually on a clean build machine) after the developer has checked in his changes. I wasn’t trying to explain SCM in detail, merely make the OP aware of its existence.
jschell wrote: Better to figure out what files are actually required. It becomes obvious with a clean extract.
But if you aren’t following an SCM process it is better to err on the side of caution. Especially if (as is the case with the OP) you aren’t sure what you need to track to begin with ... you can always fine tune by dropping items over time as you gain a better understanding. It’s harder to fine tune the other way.
|
|
|
|
|
The only bin file to put in would be the .exe or any file it requires to run (.dll?).
Think of doing a build / clean before checkin, then add in the few files needed to run your app.
(My gang keeps checking in .suo files, they come out read only and screws my ability to build...)
Note .sln and .vbproj are required, they're your solution and project files. .vb is your source code. I think .resx is generated by Visual Studio...
|
|
|
|
|
CDMTJX wrote: I think .resx is generated by Visual Studio...
.resx files are resource files. They can potentially contain images, icons, strings, and other data necessary for your program. If .vb is source code then .resx is source ‘non-code’.
|
|
|
|
|
Yup, I wasn't clear... VB creates .resx during project editing, not during building. So it is required to build with, not the result of a build, and not edited by programmers (though I've been known to edit such files with C++ and C#...).
Check .resx into source control.
|
|
|
|
|
Hi,everyone! I want that a XML file be open when Form1 had been load, before my application was killed, this XML should stays open and different Form could call it . I tryed use "Public Shared xml as new XmlDocument () ", but in Form2's control event, when I input "xml.", it didn't show the list of properties and methods.
It seemed like "Public Shared" disabled?
What should I do？
Please give me some suggestions! Thank you very much!
|
|
|
|
|
Because xml is not specific to Form1, it really should be put in a code module and not in the form. You will not need to use the Shared keywork in that case. I expect that will fix your problem.
|
|
|
|
|
Hi,Gregory! Thanks for your suggestion, my problem has been solved!Thank you very much! 
|
|
|
|
|
hi,can i just find out on how should i write my codes if i want to plot line graph in my program?
|
|
|
|
|
Here's a start[^]
I don't speak Idiot - please talk slowly and clearly
'This space for rent'
Driven to the arms of Heineken by the wife
|
|
|
|
|
TextBox8.Text = RxReadAP(3)
TextBox8.Text = Math.Round((0.0996 * TextBox8.Text + 25.603), 1)
i like to draw a line graph on vb using the temperature taken.. how do i write a code for this ??
modified on Wednesday, October 27, 2010 2:14 AM
|
|
|
|
|
I think you could use an ownerdrawn control to draw your graph
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
