Markdown Monster
Some Subversion Questions
Since I know a bunch of you are using Subversion I'm going to lean on 'ya all for a few questions that I've run into while using Subversion here.
Since I last posted about Source Control I started using Subversion for source control fairly extensively on a host of projects. As many had suggested in the comments of that post Tortoise SVN can get quite addictive and it's true enough. It took me a while to warm up to that idea, but I've become quite enamored with the shell extension and don't miss the source control inside of VS.NET at all. Life's been good and I have a shared depository running on my site for the last few months.
There are a couple of things that I need some best practices advice on.
Exporting to SVN and getting a Checked out Copy
I've started creating a secondary repository for all sorts of different development stuff that's a bit older, just to have it stored away etc. So I've been creating a bunch of new repository folders and adding projects into them.
Even with having gone through this process a bunch of times now I still haven't found a really clean way to create a repository on the server. What I seem to have to do to make this really fly is:
- Clean up my folders to get them ready for Export
- Do the Import into SVN
- Delete or rename the directory
- Use Check Out to get a local Working Copy
I tried a bunch of different ways to do this but the above seems to be the only way to go from a plain directory to a directory that's under SVN control. Is there an easier way? It seems that Import should somewhere have an option to automatically put the uploaded files under source control, but the docs actually say that that's not so. Doing a Checkout on the existing folder also doesn't work as Tortoise will not override existing files apparently.
Am I missing something?
Branching Individual Files
I'm currently working with both VS.NET 2005 and VS.NET 2008 for a couple of .NET 2.0 projects. I basically have separate folders for VS 2008 and VS 2005 where I store my projects which works fine for the main projects. However, for my library projects - Web Controls, Business Object Library, Utilities etc. - these libraries I'd actually like to share between versions because they're used in both. So for now I have a my Projects2005 branch on disk and a Projects2008 branch and each of the project folders under Subversion control using the Subversion to keep the two folder versions in sync.
It actually works well, except for one thing. The project files of course are incompatible between versions so I have to be careful when updating (or rather not updating) the project file with the Subversion repository.
So I thought it would be nice if I could just branch the project file or at least exclude the project file from the VS.2008 folder, but I haven't figured out a way to do this. I can't quite figure out how to remove the files from version control but leave the file actually there in such a way that an update won't put an updated file back.
In short I want to be able to update the file without Subversion knowing about it or wanting to update the file.
I suppose there's another workaround which is just to copy the project file give it a new name and don't add that file to SVN, but I'd like to avoid that if possible.
This is probably doable but after futzing around with this I can't quite see how to get it done...
Other Posts you might also like
The Voices of Reason
# re: Some Subversion Questions
You can do the things you're talking about through the command line using the instructions in the book, or using the Repo-Browser in TortoiseSVN. Its a skinny book, read it twice. There's a couple of pages in there that are just real gems and I keep going back to them about once a quarter for this type of stuff.
# re: Some Subversion Questions
There's no other trick to getting a project under source control. The way you're doing it is the way it's intended to work. The clumsy part of it only happens for the guy on the team that does the initial import, since he's also already got the code on his box, and would probably just prefer that code to be converted into a working copy. For everyone else on the team, it's just a matter of doing a plain-old checkout.
It likely feels weird to you since you're always the guy doing the import. Since the frequency of doing an initial import compared with the rest of the operations that happen against the repository during the life of the project are sufficiently infinitesimal to barely even deserve a mention, and since it only effects the person doing the initial setup work for the project, there isn't much call to add special features to simultaneously do an import and an in-place conversion to a working copy. It's a low-frequency feature that if implemented would have to be maintained forever. Since the scenario can already be served with two existing features, and since the feature would be used rarely, its cost would out-weigh its benefit.
# re: Some Subversion Questions
For gory details:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.ignore
# re: Some Subversion Questions
# re: Some Subversion Questions
The import thing got me too. All you have to do is create your project folder in the svn repository (IE: svn://myrepo/MyWebApp), then right click the project folder on your machine (IE: D:\Dev\Web\MyWebApp) and select 'SVN Checkout'. It will prompt you with the checkout dialog, browse to your repository project folder (IE: svn://myrepo/MyWebApp), the checkout directory (On your local machine) should default to the project folder you right clicked. Click OK and then YES to the "warning" dialog that appears (that states that the checkout folder is not empty). Now right-click the project folder again and select "SVN Commit", this will allow you to select and commit the contents of the folder. This essentially 'hooks up' your folder to the svn folder and then adds (imports) the files. So you shouldnt have to do the import/rename/delete/checkout song and dance.
One thing to remember though, if you are excluding files or folders, is not to accidentally commit them by doing a 'select all files'. For example if you are excluding bin/obj folders make sure they are unchecked in the commit dialog. Once you have commited the files/folders you want, then you go back and set the exclude properties on the commited folders.
m
# re: Some Subversion Questions
I don't think anyone mentioned that the alternative to Import is Add. You can add your project rather than importing. In addition, adding allows you to ignore stuff. So, if you add you new project you can ignore your obj, bin folders, your user files, etc.
You also don't need a new repository for each project. You can put everything into the same repository. So, when you do an add you can just specify a new folder trunk in an existing repository, for example, myprojectname/trunk in the add dialog.
Once the add is complete your working folder is already a checked out project.
BOb
# re: Some Subversion Questions
1. Create "MyProject" repository
2. Checkout MyProject/trunk to my working directory
3. Commit all my existing code
Regarding #3, After checking out the trunk to just my top level folder, I do a "Commit", which will show me everything that hasn't been added. Then I just designate everything that should be ignored (bin, obj .suo, etc) and commit the rest. I prefer using TortoiseSVN "Commit" to using "Add" because I can set up my ignores at the same time that I am setting up my adds. This gets it all done in one dialog.
For a while I used Ankh to set up projects because it knew what to ignore, after which I would
disable Ankh and use TortoiseSVN. It took a while for me to find a way of setting up SVN projects that I was comfortable with, but now it's pretty routine, and I'll probably try to write a powershell script to automate it.
Regarding your branching issue, that's a tough one. We decided not to use Branching. It's great for "feature branches", but branching is really only useful if you're also merging stuff back in at regular intervals. For example, we created an "MS AJAX branch" when AJAX 1.0 was released, and once it was stable, merged it back into the trunk. For VS versions, we did things differently. I haven't used 2008 yet, but here's how we did it for 2003/2005:
We have a "Common" solution containing lots of reusable stuff in several projects. We needed to version it for 1.1 and 2.0, so we did what NHibernate did. We have multiple project files: Common-1.1.csproj and Common-2.0.csproj. That way we can exclude Generics-related classes. You shouldn't need to exclude the other project file from your folder, just don't use it in the solution. So this means the different projects share many of same files. If a particular file needs to contain *both* 2.0 and 1.1 versions of the code, we can have the project file define a constant (NET_2_0) and wrap the 2.0 code in directives like:
#if NET_2_0
IList<T> List<T>();
#endif
# re: Exporting to SVN and getting a Checked out Copy
"So you shouldnt have to do the import/rename/delete/checkout song and dance. "
Haha... no you just have to select all of your files all over again! How that's easier than renaming and re-checking-out I'll never know.
Bottom line, this is an ass backwards feature of the program. Obviously if you're importing into the repository, you want those files to be under version control. So why not do it?
My boss recently told me to change from _svn to .svn. I figured tortoise would make the change to all of my projects for me. Nope. Now I have to go in and check out each one all over again. First of all, the checkout and commit method doesn't even work for me. I get "file already exists" errors. Second of all, I'll be damned if I'm going to go through and select all of the project files for about 50 projects. I'm wishing ill will towards the Tortoise SVN programmers right now.
# re: Some Subversion Questions
I have been using it for months now and it beats having to have a separate check-out from VS.NET. It is not a native source control provider but I have not seen any drawbacks.
No, not affiliated with them at all.