Do you always follow the convention of putting branches, tags and trunk directories at the top level of your Subversion repository? Lately, I have stopped bothering and nothing bad has happened (yet)!
It should be possible to move directory trees around if there's ever a need to create them. Am I building up trouble for later?
Have you tried branching or tagging yet? Until then, there's no problem. However, an added benefit of using the branches,tags,trunk convention is that it's exactly that -- a convention. People expect to see that, so they know what to do when they need to fork.
Nope, have abandoned that approach for the projects currently in the queue. While the concept seems very valid, it just seems to waste more time than it saves in practice.
This depends on how big the project is. We have some stuff (granted, in git, but the concept is the same) that is fairly big. Every developer uses his/her own branch, there is a testing and mainline branch. We also tag the releases, and if there are version-specific fixes, a branch is created so fixes can be integrated fairly easy.
This setup has advantages: we don't get in each others hair during developement. But the downside is that we need an integrator to put the commits from the developers branch into the testing branch, and then to the mainline one.
If the project is small, then it's just overhead, but you never know how big a project will get.
Do you at least have a trunk? If not, when you do need to branch or tag, you will have to have those sitting in your root project directory, alongside the actual code/contents. Yikes!
EDIT: I guess you could create a trunk folder, then move everything into that, then create your branches etc...
To those saying "just do it later, don't waste time, etc..." Honestly though, how much overhead is it to create them at the outset of your project? 2 minutes, tops? Why not just do it then? It will take much longer to move everything later - even if you only end up needing to branch 1 in 5 times, I still think you'd use less time starting with a branch, tag, trunk structure.
I just started to actually use the convention, and I agree with Danimal. If you have one build in QA, and another in Production, and another in crazy-new-experimental feature development, it's nice to quickly switch back and forth between them.
As I said in http://stackoverflow.com/questions/16142/what-does-branch-tag-and-trunk-really-mean#114384, since branch and tag are the same, you are not obliged to follow any convention but your own.
Especially for a small project with sequential development (i.e. no need for parallel efforts between current development, maintenance of older versions, exploration of alternative frameworks, ...)
I'll generally keep my trunk in the root of the repository and only move it into a Trunk folder if I actually need to create a tag of a branch. I think with SVN, as long as your structure is logical, you should have no trouble rearranging it later if your needs change.
I use trunk, tags and branches on every project. Seriously, how hard is it to create 2 extra directories when you create the project. There is some benefit to following the convention just to maintain consistency. I find that I have lots of tags (each push of an app outside the developer environment gets versioned and tagged). I don't have so many branches because I'm generally not working with people I don't trust with a commit prior to review. So, usually when I get branches, it's because I have a permanent splitting of the codebase - usually for different clients. Once the code becomes irreconcilable, I generally stop a branch and move it to it's own trunk.
Lately i´m using a model more focused in agile and you can take a look here.
It´s really important to following some policies in version control, cuase even using a well defined model, code version is in nature something that leads you to commit mistakes, messy merges, and all that bad stuff, so be careful.
This model gives responsibilities for each repository and does not let you overlap where you production, deliverable and under-construction code lies.
I follow the convention for numerous reasons
In short it may not be immediately obvious why the convention is a good thing, but it's when you need help, advice, or some management craziness that it becomes a proverbial godsend.
I like to use the branches for "mini-projects" for simple proof of concepts. It's fast, easy and generally helps to keep up with your main project. I put proof of concepts in the branches directory since it isn't apart of the main project but it is of value to the project.
Like others have mentioned, I use the tags for releases. Most releases I do are in versions so I generally just have a zip file of the package or the version'd installer.
Quick answer is "do whatever best suits your procedures".
As Danimal said the structure of branch/trunk/tag is a convention. However, I don't agree that it's the location of the b/t/t that is important, merely the existence of them.
What you should have is somewhere that is obviously designated for branches, somewhere designated for your trunk and same for your tags. Exactly where they fall depends very much on the structure of your repository and the nature of the files that you're keeping.
For example, if you are keeping multiple projects in one repository you'll probably find that it makes more sense to create your b/t/t directories under your projects. If you have distinct modules within your project then the b/t/t should be created under the module directories.
Ask yourself what the biggest logical chunk is going to be that you wish to branch and be guided by that.
No. Not the last 3 work situations. I work with non-programmers who need to write, fix, and recall processing scripts. Programming is mostly casual, with occasionally deeper or bigger work. There's no expectation of following big-time software developer's practices. The standard repository terminology can clash with jargon used in the field we work in. So we make up our own repository directories.
In a very straightforward environment, you can get away with leaving out the branch, tag, trunk from the top of your SVN repository. For example, if you're using SVN for your university assignments, you're not going to be very concerned about changes to the code after it gets released to your customer (the person marking the assignment), and so you could sensibly dispense with branch, tag, trunk, and just have one structure. (Effectively, the whole thing is the 'trunk'.)
If, on the other hand, you've been managing code that is deployed to 700 different sites and that is split across separate product lines, you'd be insane not to use 'branch, tag, trunk' near the top of your structure (there's a sensible case for splitting your products before going down the BTT route), since you're going to need to know what code went where, and to be able to separate major rewrite activity (the stuff you do in the trunk) from spot fixes to help a site having an immediate problem (which you do in a branch, then merge into the trunk). And if you want to be able to answer the question "Why did the Foobar stop working when we rolled out patch 1.2.3?" then tags are essential.
I've written tools in the past to automate certain pieces of SVN. Creating a basic repository is one of them. Step 1: create an empty repository. Step 2: create trunk, branches and tags folders - commit Step 3: Copy hook scripts to new repository
One of my hook scripts is to make sure that the items in the tags directory cannot be modified. This makes tags have a meaning different from branches.