Code center > Darwinbots3
DB3 Versioning
Cyberduke:
In fact maybe the solution files shouldn’t go in the SVN altogether, since that would allow me to use VS2008 and just put whatever collection of modules in my solution I wanted. And if someone wanted to use a different IDE they could, Framework 2.0 code is still Framework 2.0 code
Edit:- Ah this will screw up Nunit... and XNA... bad idea, abort abort.
Numsgil:
--- Quote from: Cyberduke ---Yes...
If the modules (assemblies) are going to be totally independent then they should probably have their own SVN trunk and branch structures, they can still come together in the same VS Solution. I think that’s what you meant
Edit:- You would want to build a solution file for each release version though. Other than that they are probably big enough sections of code and so isolated that you would probably only be working on one at a time.
--- End quote ---
I mean this sort of file structure:
--- Code: ---Modules\
DNA\
Trunk\
Branches\
Tags\
Physics\
Trunk\
Branches\
Tags\
vs.
Trunk\
Modules\
DNA\
Physics\
Branches\
Tags\
--- End code ---
It should be set up so that if the code is at version 3.42, I can go back and build version 3.26. It doesn't necessarily have to be easy, but it should be possible. But if branching and tagging works on the level of modules, we can't easily tag version global version 3.26, since version 3.26 might involve different versions of a dozen different modules. Also, it means that coders have to maintain a dozen different SVN projects. Making sure you're synced to trunk on every module would be extremely tedious.
--- Quote ---* hot swappable implies to me that it can be done while the application is up and running, which of course we can do easily enough via a drop down menu etc. Just unload one assembly and load in the new one. But is that what you meant?
--- End quote ---
Yes, that was my thinking. Maybe run two DNA assemblies at the same time. Have on species use regular DNA, and another use a custom neural net module.
--- Quote from: Cyberduke ---In fact maybe the solution files shouldn’t go in the SVN altogether, since that would allow me to use VS2008 and just put whatever collection of modules in my solution I wanted. And if someone wanted to use a different IDE they could, Framework 2.0 code is still Framework 2.0 code
Ah this will screw up Nunit... bad idea abort abort..
--- End quote ---
Right now the NUnit tests are run as a post build event. It should be IDE independent, other than setting up the post build event (or running from the NUnit GUI or whatever). Do you need different project files between 2008 and 2005? That'd be a pain.
Cyberduke:
--- Quote from: Numsgil ---
--- Quote from: Cyberduke ---Yes...
If the modules (assemblies) are going to be totally independent then they should probably have their own SVN trunk and branch structures, they can still come together in the same VS Solution. I think that’s what you meant
Edit:- You would want to build a solution file for each release version though. Other than that they are probably big enough sections of code and so isolated that you would probably only be working on one at a time.
--- End quote ---
I mean this sort of file structure:
--- Code: ---Modules\
DNA\
Trunk\
Branches\
Tags\
Physics\
Trunk\
Branches\
Tags\
vs.
Trunk\
Modules\
DNA\
Physics\
Branches\
Tags\
--- End code ---
--- End quote ---
Yeah that’s what I was trying to describe
--- Quote from: Numsgil ---It should be set up so that if the code is at version 3.42, I can go back and build version 3.26. It doesn't necessarily have to be easy, but it should be possible. But if branching and tagging works on the level of modules, we can't easily tag version global version 3.26, since version 3.26 might involve different versions of a dozen different modules. Also, it means that coders have to maintain a dozen different SVN projects. Making sure you're synced to trunk on every module would be extremely tedious.
--- End quote ---
Thats starting to sound complicated...
--- Quote from: Numsgil ---
--- Quote from: Cyberduke ---* hot swappable implies to me that it can be done while the application is up and running, which of course we can do easily enough via a drop down menu etc. Just unload one assembly and load in the new one. But is that what you meant?
--- End quote ---
Yes, that was my thinking. Maybe run two DNA assemblies at the same time. Have on species use regular DNA, and another use a custom neural net module.
--- End quote ---
Yeah, just load up all the assemblies in a "module" folder then run though them all looking for the DNA class type, make an instance of each one it finds and then add it to a dictionary, then you just need to look up which instance to use when.
--- Quote from: Numsgil ---
--- Quote from: Cyberduke ---In fact maybe the solution files shouldn’t go in the SVN altogether, since that would allow me to use VS2008 and just put whatever collection of modules in my solution I wanted. And if someone wanted to use a different IDE they could, Framework 2.0 code is still Framework 2.0 code
Ah this will screw up Nunit... bad idea abort abort..
--- End quote ---
Right now the NUnit tests are run as a post build event. It should be IDE independent, other than setting up the post build event (or running from the NUnit GUI or whatever). Do you need different project files between 2008 and 2005? That'd be a pain.
--- End quote ---
Yes, well we can play about with that at another time, it’s not really important for now I suppose. There are all kinds of options for automatically building all the project and solution files, with this exact scenario in mind (Multiple IDE’s).
XNA 2.0 only works on VS2005 and XNA 3.0 will allow it to work on VS2008 but I haven’t looked into what the difference actually is. I have both VS2005 and VS2008 anyway. So forget this for now and we'll use VS2005 for simplicity
Numsgil:
--- Quote from: Cyberduke ---
--- Quote from: Numsgil ---It should be set up so that if the code is at version 3.42, I can go back and build version 3.26. It doesn't necessarily have to be easy, but it should be possible. But if branching and tagging works on the level of modules, we can't easily tag version global version 3.26, since version 3.26 might involve different versions of a dozen different modules. Also, it means that coders have to maintain a dozen different SVN projects. Making sure you're synced to trunk on every module would be extremely tedious.
--- End quote ---
Thats starting to sound complicated...
--- End quote ---
Yes, I'm going to have to play with it this weekend. Maybe I can set up some batch files to handle the complexity, and just require people to install a command line version of SVN or something. I like the idea of tagging and branching individual modules, since it allows different paces for development for different systems. But there are practical issues that need to be addressed.
Navigation
[0] Message Index
[*] Previous page
Go to full version