Anyone know how to work SVN?

[scootermaster]

I'm working on a software project. It's pretty big, but luckily I am [now] the only one working on it. I would like to start using a versioning software, if only because I'm tired of having directories like "backup", "backup1", "back_working" and the like.

So, my first question is: Does anyone know SVN? Are there any good walk throughs? I've read a bunch of stuff on it, and I'm not even sure it can do what I want to do.

What do I want to do? Glad you asked!

I have a couple of different "versions" of the project I'm working on (actually, there are just a bunch of forks of the compiler that I use, so I have different versions for each of those) and occasionally I do a major paradigm shift were I take the codebase and change something, but I want to also have it work the old way. But that happens infrequently. Anyway, so I take this code, edit it locally, and then upload it back up to the sever to compile it (I don't have the compiler on any local machine). This is done VERY incrementally, (i.e. I add a line of code, recompile, etc).

So I'm wondering what's a good workflow? Checkout from the SVN on my server to another local dir on my server, edit the files locally, upload, (repeat) and then check back into SVN when I'm done? How will this work with my compile environment? Meaning that I might edit only a couple of files, but to compile correctly, I obviously need everything their dependent on. Does SVN handle this, or do I just need to [manually] make sure my "work" directory has copies of everything, and just overwrite the files I'm editing? I could, of course, check out everything I need to compile, but that seems overkill if I'm only editing a coupe of files.

What about hosted SVN solutions? Web -> Local computer -> remote server/compile -> back to web?

I can provide more detail/examples/clarification if needed, but I'm just wondering if anyone has any experience with any of this. It's all pretty damn confusing to me, but I'd like to have my project more organized.

Thanks!

 

[Drakkon]

I used http://cvsdude.com in the past for PHP/Flash and its worked GREAT.
Work flow for me always went checkout file from server - make edits local - local compile (You don't compile to the SVN - you compile on your local machine) - if good then commit back to server (the term in SVN for upload) - wash/rinse/repeat

When you initially create the SVN you'll create a directory. From there you will start committing files to it and it will start version-ing those files. So if you have any includes you commit those files the first time you create them and save them then once every time you edit. The SVN manages it all and will have copies of each separate file so no need to worry about the compile copies of everything.

Using a tool like TortoiseSVN if you can is great as you can do forks/merges/commits all from within windows via a right click and makes it setting it up across multiple machines really easy. They also have some great tutorials on their site. If your not using windows tools like Eclipse can do it similarly.

 

[scootermaster]

Originally posted by: Drakkon
I used http://cvsdude.com in the past for PHP/Flash and its worked GREAT.
Work flow for me always went checkout file from server - make edits local - local compile (You don't compile to the SVN - you compile on your local machine) - if good then commit back to server (the term in SVN for upload) - wash/rinse/repeat

When you initially create the SVN you'll create a directory. From there you will start committing files to it and it will start version-ing those files. So if you have any includes you commit those files the first time you create them and save them then once every time you edit. The SVN manages it all and will have copies of each separate file so no need to worry about the compile copies of everything.

Using a tool like TortoiseSVN if you can is great as you can do forks/merges/commits all from within windows via a right click and makes it setting it up across multiple machines really easy. They also have some great tutorials on their site. If your not using windows tools like Eclipse can do it similarly.

This is great, but I can't compile locally. It HAS to be on the server. So my workflow, as I said, would have to be either use a [terminal?] SVN client on my server, checkout to a directory on my server, grab the file, edit it locally, upload it, compile, and recommit when done.

I actually have Tortoise and it's a slick program. The problem is, having the files locally doesn't really do me any good. I'd have to send them to server anyway to compile. If I edit them "remotely" with WinSCP, I can edit them locally, and when I save it will automatically upload it back. You see what I'm saying?

But this still doesn't address the issues of dependencies? Do I just checkout the whole directory? I guess that's not such a bad thing. Then edit the files I want, then check the whole directory back in. Will SVN know that only a few of the files have changed and not "version" the rest of them, since they're the same?

Any other thoughts?

 

[Drakkon]

If I want to edit "index.php" and it has statements requiring/including "file1.php" and "file2.php" I still only need to check out "index.php" to edit it. You shouldn't need to checkout the dependencies. If you were to check them out and make no changes then SVN will recognize that and not up their version number. The only time it ups the "version" of them is when it notices a true file change (line by line).

 

[scootermaster]

Originally posted by: Drakkon
If I want to edit "index.php" and it has statements requiring/including "file1.php" and "file2.php" I still only need to check out "index.php" to edit it. You shouldn't need to checkout the dependencies. If you were to check them out and make no changes then SVN will recognize that and not up their version number. The only time it ups the "version" of them is when it notices a true file change (line by line).

Well, yes, you can edit it without problems, but what if you want to compile it?

In that case, your work environment needs to have file1 and file2.php, no? That means you'd have to check out all of them, right? Does SVN keep track of that sort of thing for you?

 

[hans007]

Originally posted by: scootermaster

Originally posted by: Drakkon
If I want to edit "index.php" and it has statements requiring/including "file1.php" and "file2.php" I still only need to check out "index.php" to edit it. You shouldn't need to checkout the dependencies. If you were to check them out and make no changes then SVN will recognize that and not up their version number. The only time it ups the "version" of them is when it notices a true file change (line by line).

Well, yes, you can edit it without problems, but what if you want to compile it?

In that case, your work environment needs to have file1 and file2.php, no? That means you'd have to check out all of them, right? Does SVN keep track of that sort of thing for you?

uh, thats not really what source control is for.


if you organize the folders correctly then you can just sync them all down before running it. you dont compile... php.


svn is pretty good i'd say. i like it better than cvs. its not perforce or anything, but svn works pretty well.

 

[tfinch2]

SVN = SCM = Source Control Management, not Source Compile Management.

Usually your build environment and SCM are separate entities. It usually goes something like this in my experience:

You have an SCM that everyone checks their stuff into. You sync your local copy with the SVN server to get the most recent revisions before you do a local build. You always have a workspace with the files in the source tree. Them being the most recent revision depends how often you sync your workspace. If there is a new file that you don't have in your workspace, you have to sync to get it.

You only check a file out if you want to make changes to it. Usually files that are not checked out are read-only so you can't make edits to your local copy. Once you are done editing, you check that file back in. The next time everyone refreshes their workspace, they get the most recent revision of the file you just modified.

This is probably irrelevant to you, but once you are ready to do an official build, the source tree is locked so nobody can check anything in or out. You do your official build. If everything works okay and you create an official version of your software, you start a new branch on the source tree. This locks and backs up the old branch, then you start the whole process over again.

Hope that helps.

 

[scootermaster]

Originally posted by: tfinch2
SVN = SCM = Source Control Management, not Source Compile Management.

Usually your build environment and SCM are separate entities. It usually goes something like this in my experience:

You have an SCM that everyone checks their stuff into. You sync your local copy with the SVN server to get the most recent revisions before you do a local build. You always have a workspace with the files in the source tree. Them being the most recent revision depends how often you sync your workspace. If there is a new file that you don't have in your workspace, you have to sync to get it.

You only check a file out if you want to make changes to it. Usually files that are not checked out are read-only so you can't make edits to your local copy. Once you are done editing, you check that file back in. The next time everyone refreshes their workspace, they get the most recent revision of the file you just modified.

This is probably irrelevant to you, but once you are ready to do an official build, the source tree is locked so nobody can check anything in or out. You do your official build. If everything works okay and you create an official version of your software, you start a new branch on the source tree. This locks and backs up the old branch, then you start the whole process over again.

Hope that helps.

Okay, this is helpful.

So I could do an initial submit, or whatever, where I build the tree of files (I'm not so sure how to do that so it's how I want, but we'll get to that later). Then I get all the files, without checking them out, so to speak. Then, I check out the files I want to edit, edit them, build them with my "local" copies of files, and then check back in the modified versions when I'm done?

As I said in the OP (did anyone actually read that?) the main reason for me wanting to use SVN is to facilitate easier backups and rollbacks to previous versions of my code, as well as helping to organize the directory structure.

So that'll work, right?

 

[tfinch2]

Originally posted by: scootermaster

Originally posted by: tfinch2
SVN = SCM = Source Control Management, not Source Compile Management.

Usually your build environment and SCM are separate entities. It usually goes something like this in my experience:

You have an SCM that everyone checks their stuff into. You sync your local copy with the SVN server to get the most recent revisions before you do a local build. You always have a workspace with the files in the source tree. Them being the most recent revision depends how often you sync your workspace. If there is a new file that you don't have in your workspace, you have to sync to get it.

You only check a file out if you want to make changes to it. Usually files that are not checked out are read-only so you can't make edits to your local copy. Once you are done editing, you check that file back in. The next time everyone refreshes their workspace, they get the most recent revision of the file you just modified.

This is probably irrelevant to you, but once you are ready to do an official build, the source tree is locked so nobody can check anything in or out. You do your official build. If everything works okay and you create an official version of your software, you start a new branch on the source tree. This locks and backs up the old branch, then you start the whole process over again.

Hope that helps.

Okay, this is helpful.

So I could do an initial submit, or whatever, where I build the tree of files (I'm not so sure how to do that so it's how I want, but we'll get to that later). Then I get all the files, without checking them out, so to speak. Then, I check out the files I want to edit, edit them, build them with my "local" copies of files, and then check back in the modified versions when I'm done?

As I said in the OP (did anyone actually read that?) the main reason for me wanting to use SVN is to facilitate easier backups and rollbacks to previous versions of my code, as well as helping to organize the directory structure.

So that'll work, right?

Yes.

 

[kamper]

Essential svn reading

I've used svn in situations where I just had a local repository on the same machine and where I run a network server. Both are quite easy and very handy. Tortoise is a good way to get to know it (and it's all you need if you have a local repository) and has some nice graphs and stuff, but nothing beats the command line

 

[scootermaster]

Originally posted by: kamper
Essential svn reading

I've used svn in situations where I just had a local repository on the same machine and where I run a network server. Both are quite easy and very handy. Tortoise is a good way to get to know it (and it's all you need if you have a local repository) and has some nice graphs and stuff, but nothing beats the command line

Yeah, I read that, and am re-reading that.

Good stuff.

I've also played around with setting up dummy repositories and stuff. I think I got it down.

One question is with branches or forks or whatever.

So, right now, I have this directory tree, on my file system, NOT on the SVN, that's like this:

/compiler/compiler_version1/program_that_does_things_this_way/
/compiler/compiler_version1/program_that_does_things_that_way
/compiler/compiler_version1/utils
/compiler/compiler_version1/lib
/compiler/compiler_version2/program_that_does_things_this_way
/compiler/compiler_version2/program_that_does_things_that_way
/compiler/compiler_version2/utils

So when I do my initial check in, do I just check in the whole /compiler directory? Or do I set up different versions? Do I do it by compiler version (there might be three or four of these, thanks to the developers that won't merge their trunks) or do I do it by the versions of my code (which, as I stated before, occasionlly makes large paradigmatic shifts in functionality)? Or both?

The goal here is to reuse as much code as possible, and not have 43534543 versions of do_this.cc and do_this.h lying around, if theyre the same damn file, right? I'm anal, and I'd like this to be as clean as possible.

Does it make sense to re-order the directories in some other way? I put them like that, thinking that it would help to just check in the root directory, but now I'm not so sure. I obviously wouldn't want to check them all out at once...I really only work on one compiler version, and one branch of my code, at once.

Once I get that down, I think I'm ready to start. I'm excited! This is going to make me so much more organized!

And thanks so much for all your help!


Edit: One more question, and I think I'll get the hang of it. So, there's a bunch of code that I didn't write that is somewhat applicable too. There are many new files that he's written (that don't otherwise exist anywhere else) but some of the files share the same name as files that are in many/all of the branches that I use. To further complicate things, some of these "same" files really are the same -- identical -- but some have added/changed code with functionality that the versions I use don't have (gee, it's almost like we should have used a versioning system!). Where's the best place to put these, in terms of the file system? Like, /compiler/compiler_version1/not_my_code? And more importantly, what's the best way to check these files in? Is there a way to diff some of these files and then add the code (if it's needed) to the versions that I use? And then, perhaps, delete the useless copies? This aspect seems like it may be somewhat influenced by my build environment. But the point is, I'm not sure how to handle these pre-existing "branches".

 

[kamper]

Subversion doesn't really care much about your branches. The conventional way of doing what you're doing is to have three directories at the top level of your repository: trunk, branches and tags. trunk holds the primary version of your code, tags hold frozen-in-time snapshots, like of releases or something, and branches holds side trees that are variations on your trunk. However, this is just convention and svn doesn't provide a whole lot of specific support for tracking changes across the various branches. As far as the repository is concerned, it's all just a bunch of directories with code in them.

If you don't want to have multiple versions of code sitting around, you'll have to think about restructuring your build process so that common files are all pulled from the same place. Figure out how you would lay it out to minimize complexity without svn, and then check it into the repository for the first time like that.

However, if you do have code duplicated across your versions, diff is a pretty powerful tool for tracking the differences. If you ever want to pull code from one branch to another, just diff them and focus in on what is should be the same (as opposed to the parts that are intentionally different).

There are also scms like git or mercurial that are designed to ease working with multiple complete copies of a tree. I'm a little out of my league recommending them to you, as I've never used them, and it seems odd to recommend them to a single developer when they're primarily used for really distributed development, but they might provide you with a better model for what you're trying to do.

 

[Modeps]

I honestly have not read the thread, but your title asked for hosted solutions. I use http://beanstalkapp.com for my hosted SVN system. Its free up to 20mb (I wish it was a little higher), and pretty easy to use.