Help on working with branches?

neocookie
neocookie
Hi all    I've set up my repository similar to the following:  releases / (tags)   client1 /   1.0 /   1.1 /   client2 /   1.0   client3 /  trunk /   libraries / (third party libraries)   tests / (unit tests)   webapp / (web application)   www / (normal www)  branches /   client1 / (specific config files, images, etc)   client2 / (specific config files, images, etc)   client3 / (specific config files, images, etc)    I believe this to be the best way to proceed. However, I'm a little unsure as to how things work with the branches.    From the SVN book, it says that branches are "cheap copies", which I understand. What I don't understand, however, is what happens when a file in the trunk is updated after a branch has been made. Does the alteration reflect in the branch?    For me, this is quite important as the branches for my project will rely on the latest trunk code, which will be all the business- and data-logic for my client applications.    Can someone help?

Last updated

mike5
mike5
A branch is a "cheap copy" as you put it, of a file at a certain point in time, i.e. revision number.    If you continue working on the trunk, the branch will be unaffected, it will still point to its original revision. If you switch, and start working on a branch, this will also not affect the trunk. And you will still have available the entire history of the branch, from it's creation point on.    Tag is exactly the same, a "cheap copy", but all your developers must agree, that they will not touch a tag, because it is not protected.    If you want to protect it, you must create a hook script, that does that.    Cheers, Mike5
Manuzhai
Manuzhai
Your changes on the trunk will not be propagated to the branch. You can use svn merge to merge changes from the trunk into a branch.
kroland
kroland
Manuzhai, your statement implies that it is not possible to share a common, changing code base between multiple "versions" of a repository. I am also looking at converting from PVCS to SVN and this statement makes me question if I understand what process changes will result.    For instance, I have an archive that builds on 6 different platforms. Since each platform builds from a "project" file, I have 6 different versions of this file. Therefore, this single file has 6 different branches, with six different floating labels. All 6 tags are present on all of the rest of the files (which are the same for all platforms), so a build of any platform will retrieve all the necessary files and the one special project file.    All the other files change, but the floating label moves with them, so I always have the latest files when I build any one package. How _does_ one accomplish this feat in SVN without constantly merging the trunk back to a branch. It sounds like a lot of work, but I am hoping that there is just a "different" way of accomplishing the same goal.
the_jeff
the_jeff
I think you are going to be out of luck.    http://www.svnforum.org/forum/viewtopic.php?t=214
mike5
mike5
Can't you construct your "project" in such a way, that it gets the platfrom specific files from some other location, and not from the trunk?    Cheers, Mike5
neocookie
kroland
kroland
"You cannot do it" or "put those files into a separate directory" is what I expected to hear. In theory I am not opposed to this difference in philosophy, but it will make it difficult to migrate the current projects to subversion. This is a very common "pattern" for us.    Moving forward, if we choose subversion, I have to somehow wrap my head around this different way of thinking. It is difficult to see how it will play out for complex, multi-platform projects.    Thanks for the help everyone.
mike5
mike5
There is also a suggestion for using svn:external. Have you missed it?    Cheers, Mike5
Robert Schneider
Robert Schneider
I think branches could be the wrong approach to manage the different versions of a (OS-) specific problem. I could imagine those files should be placed in one common directory of the project. In svn it would be also just a common source file subdir. Not a branch.    Now, to build specific releases you do a checkout or export as usual. But instead of building all what is in your directory, just use the appropriate files and directories. So it becomes a question of the build managment (there are also tools available for this part of the software development (ant, make, ...)) and not anymore of the source control system. And that means that you do not need to use the branches in svn, which I think are intended for bug fix and experimental development (and maybe other things, but not for this problem).    Can anyone agree to this proposal? Would be interesting to read some comments.

1-10 of 10

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.