Just recently started using subversion as my source control system. I'm the sole developer for my project.

How often should one commt? Daily, every other day, weekley?

Do you commit one file at a time or multiple files? I notice with subversion, there is a change log feature that allows me specifiy whats changed. If I commit serveral files this log file could have many changes. So is it better to commit one file or multiple files.

Should a commit be performed only after a change is complied and working?

Any other help tips would be great.

Eric

erichar11 wrote:

Just recently started using subversion as my source control system. I'm the sole developer for my project.

How often should one commt? Daily, every other day, weekley?

Couple of times a day.

Commit a lot. So if you're working on something in the morning and you're going to work on some other function in the afternoon, commit at noon, log the change. This way you can revert the work you've done in the afternoon if you don't like it, but keep the changes you've made in the morning, without any hassle

Do you commit one file at a time or multiple files? I notice with subversion, there is a change log feature that allows me specifiy whats changed. If I commit serveral files this log file could have many changes. So is it better to commit one file or multiple files. Should a commit be performed only after a change is complied and working?

I commit solution folders. I've chopped up the project in multiple solutions (drivers, runtimes, templates, documentation, designer, code generators, SDK etc. etc.). When I work on one solution it's for a piece of functionality. So when I'm done with it, I log it. I don't log work in progress when I commit the changes at the end of the day. I commit changes at the end of the day, because I'm not breaking a build with that. In a team, you should commit to your own branch, so you won't break the build in the trunk. (I also commit to a branch, I commit bugfixes to the trunk).

So, new development: make a branch, develop to that, log occasionally (IMHO), for example milestone activity: "finished feature ABC". Bugfixes/issue resolving: work on trunk, log bug/issue in bugtracker system, make changes, test and then check in with the bug/issue number as log. This way you can find back when you've fixed which bug. Details of a bug is logged in the bugtracker

When development is done, simply MOVE trunk to tags, and copy dev branch as trunk, that is with large development (v2.0 for example, if v1.0 is in the trunk). When you've done minor development, you could also opt for a merge on the trunk, but taht can be time consuming.

Hi,

Is there any particular reason why you are using subversion over and above Microsoft SourceSafe? Is that not any good? or is the only reason due to it being FREE?

Let me know your thoughts.

Geoff.

Is there any particular reason why you are using subversion over and above Microsoft SourceSafe? Is that not any good? or is the only reason due to it being FREE?

Well, the first version control system I used was MS SourceSafe? Overall, it worked pretty well except for it slowing the load times for my solution. Probably something that was easily to solve via some config setting, but never really looked into it. Also I guess I was a little concerned (from many postings on newsgroups) about SourceSafe currupting files, but I never experienced it myself. The primary reason I switched was the need to have the repository stored on a remote server. I needed this as I was working from home and at a clients location on a project. Subversion has several sites where you can host a repository. That worked well so just kinda stuck with it. Also wanted to get access to the LLBLGEN manager templates and needed subversion/tortise to due that. No need to have two source control systems so just decided to go with subversion. Nothing really against sourcesafe.

Eric

davisg wrote:

Hi,

Is there any particular reason why you are using subversion over and above Microsoft SourceSafe? Is that not any good? or is the only reason due to it being FREE? Let me know your thoughts.

Sourcesafe came with vs.net ent. so I had it already available here, and we used it for years, the thing is though that it gets sluggish after a while and what I didn't like was the lack of features like 'folder versioning', atomic commits and a command line client. Folder versioning is very important to get older versions back, atomic commits speak for themselves and a command line client is important so you can export files in .cmd files which for example run auto-generate builds.

Also the expensive copy action in sourcesafe is not that great. In subversion copying a version to create a tag or branch is very inexpensive. With large projects this is key. Also, the db gets corrupted once in a while. I didn't have it a lot, but experienced it once or twice.

Thanks guys, i'll take a good look at subversion then.

Geoff.

Otis wrote:

When development is done, simply MOVE trunk to tags, and copy dev branch as trunk, that is with large development (v2.0 for example, if v1.0 is in the trunk). When you've done minor development, you could also opt for a merge on the trunk, but taht can be time consuming.

So let me understand... you move /trunk to a /tags directory, which removes /trunk, then make a copy of your branch as the new /trunk? Interesting.

Cadmium wrote:

Otis wrote:

When development is done, simply MOVE trunk to tags, and copy dev branch as trunk, that is with large development (v2.0 for example, if v1.0 is in the trunk). When you've done minor development, you could also opt for a merge on the trunk, but taht can be time consuming.

So let me understand... you move /trunk to a /tags directory, which removes /trunk, then make a copy of your branch as the new /trunk? Interesting.

You can also copy the branch onto trunk, effectively it's the same. Subversion simply versions folders and their contents as one version. So if something changes, it just becomes a new version (revision).

You don't lose any versioning history, as that moves into the tag and the branch and then via the branch back to the new trunk.

Otis wrote:

You can also copy the branch onto trunk, effectively it's the same. Subversion simply versions folders and their contents as one version. So if something changes, it just becomes a new version (revision).

You don't lose any versioning history, as that moves into the tag and the branch and then via the branch back to the new trunk.

Interesting. I rarely use branches (though I do use tags to track releases) precisly because merging is such a headache. I guess it's safe to assume that you only work on one branch at a time? What happens when you have to fix a bug while working on a branch, do you do the work in the trunk and copy the work manually over to the branch, or is there some other technique you use?

Frans Wrote:

Bugfixes/issue resolving: work on trunk, log bug/issue in bugtracker system, make changes, test and then check in with the bug/issue number as log.

Frans, what experience do you have with bug trackers, and which one are you using now? I'm looking for a good one that's not too expensive (Less than $500 would be great).

Thanks, Jeremy

Cadmium wrote:

Otis wrote:

You can also copy the branch onto trunk, effectively it's the same. Subversion simply versions folders and their contents as one version. So if something changes, it just becomes a new version (revision).

You don't lose any versioning history, as that moves into the tag and the branch and then via the branch back to the new trunk.

Interesting. I rarely use branches (though I do use tags to track releases) precisly because merging is such a headache. I guess it's safe to assume that you only work on one branch at a time?

No I use the trunk for the current version and a dev branch for new stuff. I have 2 folders on my harddrive for working projects: one for the trunk and one for the dev branch. Fixing a bug is done in the trunk, committed and if I feel up to it, I merge the code using subversion with teh branch checkout on the harddisk, but I also sometimes simply copy the code over to the devbranch.

What happens when you have to fix a bug while working on a branch, do you do the work in the trunk and copy the work manually over to the branch, or is there some other technique you use?

Manually if it's small, merge if it's big. Merging is a bit of a pain, you have to do it one file at a time, which can be cumbersome with multiple-file changes, but it's the smoothest way. The merger / conflict resolver of tortoisesvn is pretty good.

Jeremy wrote:

Frans Wrote:

Bugfixes/issue resolving: work on trunk, log bug/issue in bugtracker system, make changes, test and then check in with the bug/issue number as log.

Frans, what experience do you have with bug trackers, and which one are you using now? I'm looking for a good one that's not too expensive (Less than $500 would be great).

I found out it greatly depends on how you do project management. We use modules with their own version numbers which form together a release. This is somewhat odd for a lot of bugtrackers.

I use the free Bugtracker.net: http://btnet.sourceforge.net/ . It does what it has to do, is very simple etc. We're very small, so it fits our needs. There are a lot of bugtrackers out there. With a more bigger organisation it's often good to have some sort of integration between bugtracker and sourcecontrol system. One way to do that is for example getting Vault with the new bugtracker from Sourcegear.

I used Mantis bug tracking system and it's really great. Check it out: http://www.mantisbt.org/

Have anyone used Source valut and Source Offsite? Any review? http://www.sourcegear.com/vault/

Regards, Developer

The bug tracker by axosoft is good.

From what I have been reading on vs.net 2k5 there are alot of great features that are going to be in that version. i.e. new version control, project management features, bug tracking, etc.

Lately I have been using cvs dude.org for distributed team development. With my suscription I have access to bugzilla and trac. both of which are pretty cool.

So when I'm done with it, I log it. I don't log work in progress when I commit the changes at the end of the day.

What is the difference between commiting and logging?

Also, with Subversion, if I have a web project in 'wwwroot' and some other project in 'Visual Studio Projects' and both of these projects are in the same VS.net solution, is there anyway that I can commit both projects with one click? Or would both sets of project files need to be in the same version controlled directory?

Currently, I think I need to go to the web project folder and do a commit and then navigate to the other project's folder and do another commit. Would be better if Subversion had a sense of a solution.

Developer wrote:

I used Mantis bug tracking system and it's really great. Check it out: http://www.mantisbt.org/

Have anyone used Source valut and Source Offsite? Any review? http://www.sourcegear.com/vault/

Regards, Developer

Vault user here. I'm a big fan. Very easy to use and just about every feature you would need. SQL Server backend for reliability/backup/transactional support. Decent GUI. Stay away from the VS integration stuff...nasty stuff that should be destroyed (it's MS's of course).

Only complaint is that they don't have shell integration. I spoke with Eric Sink who said he'd love to have it, so my bet is that it's forthcoming.

Jeff...

Ian wrote:

So when I'm done with it, I log it. I don't log work in progress when I commit the changes at the end of the day.

What is the difference between commiting and logging?

Also, with Subversion, if I have a web project in 'wwwroot' and some other project in 'Visual Studio Projects' and both of these projects are in the same VS.net solution, is there anyway that I can commit both projects with one click? Or would both sets of project files need to be in the same version controlled directory?

Sure, use a .cmd file and place in there 2 svn statements. It's very easy to do. For example I use cmd files like that to commit all template folders and export them as well to the test folder

Currently, I think I need to go to the web project folder and do a commit and then navigate to the other project's folder and do another commit. Would be better if Subversion had a sense of a solution.

It doesn't have a sense of a solution and that's a good thing. VS.NET stores sourcecontrol info inside project files. This is a bad thing, because if you have ever shared physical project files among solutions, you know how 'wonderful' that system is

Developer wrote:

I used Mantis bug tracking system and it's really great. Check it out: http://www.mantisbt.org/

There were some serious security leaks found in mantis last month, be sure to upgrade to the very latest version (if it's available already)

jeffreygg wrote:

Only complaint is that they don't have shell integration. I spoke with Eric Sink who said he'd love to have it, so my bet is that it's forthcoming. Jeff...

Aha, friends in high places! Great to hear they add shell integration (and probably also commandline access, which is IMHO a must for flexible sourcecontrol. I want to fire up a simple cmd file which does tasks for me, not click aroudn in a gui)

Otis wrote:

jeffreygg wrote:

Only complaint is that they don't have shell integration. I spoke with Eric Sink who said he'd love to have it, so my bet is that it's forthcoming. Jeff...

Aha, friends in high places! Great to hear they add shell integration (and probably also commandline access, which is IMHO a must for flexible sourcecontrol. I want to fire up a simple cmd file which does tasks for me, not click aroudn in a gui)

Heh. Actually, command line access already is available through vault.exe. They also have an (unsupported) public API.

Jeff...

Hi all, I know this is an old thread but I have been looking at subversion lately and found a freely downloadable pdf book on subversion, from what looks like O'reilly. Here is the link

http://svnbook.red-bean.com/

Chris [Angus]

Otis wrote:

I use the free Bugtracker.net: http://btnet.sourceforge.net/ . It does what it has to do, is very simple etc. We're very small, so it fits our needs. There are a lot of bugtrackers out there. With a more bigger organisation it's often good to have some sort of integration between bugtracker and sourcecontrol system. One way to do that is for example getting Vault with the new bugtracker from Sourcegear.

Nice tip. Thnx. I'm using it now too with/for a website i'm making. It's easy to deploy and setup.

Otis wrote:

I have 2 folders on my harddrive for working projects: one for the trunk and one for the dev branch.

Given that project references are absolute, do you maintain multiple project files so that they each reference the correct version of the files?

Ian wrote:

Otis wrote:

I have 2 folders on my harddrive for working projects: one for the trunk and one for the dev branch.

Given that project references are absolute, do you maintain multiple project files so that they each reference the correct version of the files?

Yes, the whole solution is branched. WHen dev is done, dev branch becomes a new trunk in a separate folder in svn. This because we have to do maintenance on multiple versions, so having one as a tag and another one as a trunk doesn't work that well.

Ian wrote:

Otis wrote:

I have 2 folders on my harddrive for working projects: one for the trunk and one for the dev branch.

Given that project references are absolute, do you maintain multiple project files so that they each reference the correct version of the files?

See this article on this. Your project should be self-contain... so when you version you just can copy the whole thing to a new folder. Of course, it is a bit of a pain if you use "web application" projects with IIS rather than the local server since you have to maintain the vdir's.

http://www.codeplex.com/treesurgeon/Wiki/View.aspx?title=Home

Go down to the bottom and read the 8 part article. Don't worry, each part is pretty small.

BOb