SVN terminology question

[Drakkon]

I am using an SVN to host multiple projects - each project base resides on its own folder within the trunk of the SVN. I say 'base' project as the source is general and each base project gets duplicated then skinned and features added per main project. What should be the method by which these individual projects are added to the svn - would they be a branch? a tag? or another folder within the trunk? I cannot create multiple servers but will still like to revision the individual projects.

 

[dinkumthinkum]

There is no real difference between tags, branches, and folders in an SVN repo. They are all versioned of course.

 

[LuckyTaxi]

There is no real difference between tags, branches, and folders in an SVN repo. They are all versioned of course.

What do you mean there is no real difference? You can check out each individual branches (i.e. development versus production). That could be two different set of code. Same thing with a tag. I could tag my software 1.0 and add a new module to it and tag it w/ 1.1. How is that not different?

 

[LuckyTaxi]

I am using an SVN to host multiple projects - each project base resides on its own folder within the trunk of the SVN. I say 'base' project as the source is general and each base project gets duplicated then skinned and features added per main project. What should be the method by which these individual projects are added to the svn - would they be a branch? a tag? or another folder within the trunk? I cannot create multiple servers but will still like to revision the individual projects.

Just to clarify, you want to use one server to host multiple projects under SVN? What I do is have a base folder /home/svn or something and under that I have my projects.

/home/svn/project1
/home/svn/project2
/home/svn/project3

Subversion will track each project separately. Same with branching and tagging, project1 can have 3 branches (i.e. legacy, dev, prod). The same goes for tags.

 

[Markbnj]

What do you mean there is no real difference? You can check out each individual branches (i.e. development versus production). That could be two different set of code. Same thing with a tag. I could tag my software 1.0 and add a new module to it and tag it w/ 1.1. How is that not different?

I think what he's trying to say is that they are all just copies. You can copy from trunk to a tag/branch, and then you have a seperately versioned copy of the trunk.

 

[Drakkon]

Okay I get what branches/tags are used for now - they are just a copy and nothing more - just used in various ways to keep track of updates

I was hoping to have something where project1 is on the svn server and say a project1_company1 folder is a branch/tag yet the project1 code is retained and linked to the original and re-versioned every time the core code is updated. I guess a single server svn isn't made to do this though.

 

[Crusty]

Okay I get what branches/tags are used for now - they are just a copy and nothing more - just used in various ways to keep track of updates

I was hoping to have something where project1 is on the svn server and say a project1_company1 folder is a branch/tag yet the project1 code is retained and linked to the original and re-versioned every time the core code is updated. I guess a single server svn isn't made to do this though.

If I'm understanding you right that's a pretty common usage strategy.

project1/
    trunk/
    branches/
        client1/
        client2/
    release/
project2/
    trunk/
    branches/
        client1/
        client3/
    release/

In order to 'port' changes in one folder to another you simply do a merge. You can merge over bug fixes from the trunk to a branch when you make them.

Another thing you can do is if say client3 requested a feature that is now mature enough to be incorporated into the trunk you can merge that way as well.

The way our shop is setup I'm the only person with write access to our trunk/release folders and I let the other developers have their own branch they work in. When they finish a task I'll merge their changes into my own branch for testing and then merge them to the trunk when it's ready for QA.

When a release is ready I create a tag in the release folder of the trunk with the version number of the release.

 

[Drakkon]

If I'm understanding you right that's a pretty common usage strategy.

project1/
    trunk/
    branches/
        client1/
        client2/
    release/
project2/
    trunk/
    branches/
        client1/
        client3/
    release/

In order to 'port' changes in one folder to another you simply do a merge. You can merge over bug fixes from the trunk to a branch when you make them.

Another thing you can do is if say client3 requested a feature that is now mature enough to be incorporated into the trunk you can merge that way as well.

The way our shop is setup I'm the only person with write access to our trunk/release folders and I let the other developers have their own branch they work in. When they finish a task I'll merge their changes into my own branch for testing and then merge them to the trunk when it's ready for QA.

When a release is ready I create a tag in the release folder of the trunk with the version number of the release.

I'm really new to SVN and didn't know merges could be used that way. I know there had to be a term for it. That sounds to be perfect and exactly what I'm looking to do. Thanks!

 

[Crusty]

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

Give that a thorough reading, it goes over a lot of the same stuff and more.