Jump to content

Getting Started


ShadowMage

Recommended Posts

I have been thinking, and I think a version control implementation would be a great thing to implement here at work. One problem: I have no idea where to start. Based on what reading I've done, I've concluded that there are two pieces to the puzzle: a server for the code repository, and the client which will access the repository.I'd like to set up the server on our intranet server and the client (obviously) on my workstation. My questions are: - What is a good server/client setup?- Any tutorials you can recommend on getting things set up?- Can I migrate an existing project into a VCS? Any advice/feedback/pointers you have to offer will be much appreciated. TIA.

Link to comment
Share on other sites

I set up the Collabnet Subversion Edge stack at work without any prior knowledge of SVN systems using their instructions, and managed to not completely break everything. All of my experience has been with that system, so I can't compare them. You can move an existing project, but revision 1 starts at whatever you initially define as the structure for that project.

Link to comment
Share on other sites

I set up the Collabnet Subversion Edge stack at work without any prior knowledge of SVN systems using their instructions...
I'll look it over and see if anything makes sense. I'm not going to go installing anything yet, I'm still in the research phase. ^_^
...and managed to not completely break everything.
:( That's not entirely convincing... :P
Link to comment
Share on other sites

The Subversion Edge stack doesn't seem too hard to set up. My only concern is system requirements (hardware/OS). The server I was planning on installing the VCS server on is quite old and I'm afraid it won't be able to efficiently run the Subversion server. JSG, what type of system do you run the server on?

Link to comment
Share on other sites

I'm not sure of the current hardware specs, but I think it's running Windows Server 2003. It's a dedicated IBM web server in a 1U case, I can look up the specs if it's really important. I'm pretty sure that all SVN servers are specifically designed to be inefficient and take a bunch of time apparently doing nothing at all though, regardless of what they're running on. Surely it shouldn't take several seconds to update or commit small files, but sometimes it does.

Link to comment
Share on other sites

I'm not sure of the current hardware specs, but I think it's running Windows Server 2003. It's a dedicated IBM web server in a 1U case, I can look up the specs if it's really important.
It isn't really all that important, I guess. I was just curious. Our intranet server is running W2K. :blush: So I guess I'm actually more concerned with the OS being supported...
I'm pretty sure that all SVN servers are specifically designed to be inefficient and take a bunch of time apparently doing nothing at all though, regardless of what they're running on. Surely it shouldn't take several seconds to update or commit small files, but sometimes it does.
:P
Link to comment
Share on other sites

You could look into git as well. http://git-scm.com/And you could just have it hosted on github. You can install it yourself as well.http://code.google.c.../downloads/list I have not installed it but I have setup projects on my computer to work with github and it pretty easy.

Edited by thescientist
Link to comment
Share on other sites

I've worked with both Git and SVN, although I can't really call myself an expert at either. My experiences with both echo what justsomeguy said.Comparing Git and SVN... Git and SVN are very different in their approach, with the biggest difference (from which most other differences spawn) being that SVN is a centralized system, whereas Git is a distributed system.What does this mean really? With SVN, you can move or copy the repository (i.e. not simply the files in their current state, but their history and all that), but doing so disconnects you from the "central" server completely, so this is usually only done if you switch servers. You could also instead "checkout" the code, i.e. get the files at a certain state, and place the changes back into the central server (while keeping a copy on your computer, obviously).With Git, everyone has the full repository, and there is no truly "central" server, although any device can potentially act as a server (i.e. allow others to download a repository copy from it or receive changes after an authorization). It's a matter of agreement who gets to host the master code.If your projects are open sourced, you could use GitHub as your backup/(pseudo-)central node. If not (or if you choose another Git hosting service), you could always migrate - as long as there's at least one person with a copy, everything will be intact.

Link to comment
Share on other sites

I thought about a hosted service, but I worry about security. My worries are probably unfounded, but anytime I do anything over the internet I worry... Anyway, this would be mainly just for me to use. I am really the only developer/programmer here at work, but I am working on a very large project and I'm finding that my old way of creating copies of the project directory (ie, Project_bak, Project_rev1, etc.) isn't working so well. Especially since I have been making several "branches" of my code doing a few different tasks at a time. Merging changes is a hassle at best, so I thought version control might help me.

Link to comment
Share on other sites

I am really the only developer/programmer here at work, but I am working on a very large project and I'm finding that my old way of creating copies of the project directory (ie, Project_bak, Project_rev1, etc.) isn't working so well. Especially since I have been making several "branches" of my code doing a few different tasks at a time. Merging changes is a hassle at best, so I thought version control might help me.
definitely sounds like a version control system would be helpful. Even though I am the only one who works on my personal projects outside of work, I still decided to add my most active projects to github over the weekend. It's just good to have, iMO, and the ease that it affords when branching/tagging/merging is absolutely worth the time invested. A good primer on the theory and work flows of common version control use cases can be found within the SVN documentation.http://svnbook.red-bean.com/en/1.7/index.html
Link to comment
Share on other sites

I thought about a hosted service, but I worry about security. My worries are probably unfounded, but anytime I do anything over the internet I worry... Anyway, this would be mainly just for me to use. I am really the only developer/programmer here at work, but I am working on a very large project and I'm finding that my old way of creating copies of the project directory (ie, Project_bak, Project_rev1, etc.) isn't working so well. Especially since I have been making several "branches" of my code doing a few different tasks at a time. Merging changes is a hassle at best, so I thought version control might help me.
Your fears are definitely unfounded. Besides, what's the worst that can happen? Someone logs into your repo and deletes all of your files... so what? You have a copy at your computer. If you use SVN, you'll lose your history while still keeping your latest files, and if you use Git, you won't lose anything. The only REAL question is if you want your big project's source to be known. If the answer is anything other than "no", you should definitely consider a hosting server in addition to your local copy.
Link to comment
Share on other sites

Your fears are definitely unfounded. Besides, what's the worst that can happen? Someone logs into your repo and deletes all of your files... so what? You have a copy at your computer. If you use SVN, you'll lose your history while still keeping your latest files, and if you use Git, you won't lose anything. The only REAL question is if you want your big project's source to be known. If the answer is anything other than "no", you should definitely consider a hosting server in addition to your local copy.
This is actually more what I'm worried about. Like you said, if someone deletes all the files, no big deal, I have a copy. The project's source could be considered confidential (at least in the minds of the execs :P) and so I'd like to keep it under lock and key as much as possible. So from what you've just said, I probably want to go with an on-site solution rather than a hosted solution. That said,I spoke to my immediate supervisor about setting up a VCS and he suggested installing Subversion Edge on my workstation and set up a backup schedule to push the repository to our network (in case my workstation fails). He had never heard of VCS before and was not sure if such a solution would be feasible/advisable. What do you guys think?
Link to comment
Share on other sites

I suppose if you are the only one working on these projects then setting up everything on your local machine and backing that up regularly would be sufficient, but especially if there are other developers working on the project, a VCS would be helpful. At the very least, the big benefit of any sort of VCS system is the history tracking/diffing and branching/tagging functionality. That can be help even there is one or a dozen developers working on a project.x

Edited by thescientist
Link to comment
Share on other sites

I suppose if you are the only one working on these projects then setting up everything on your local machine and backing that up regularly would be sufficient, but especially if there are other developers working on the project, a VCS would be helpful. At the very least, the big benefit of any sort of VCS system is the history tracking/diffing and branching/tagging functionality. That can be help even there is one or a dozen developers working on a project.x
If I set it up on my local machine, I would still have the history and branching functionality, would I not? I'd still have the VCS server and a VCS client, they'd just be on the same machine.
Sounds good, but... Why Subversion Edge? TortoiseSVN is much more intuitive IMHO.
TortoiseSVN is just a client, isn't it? Subversion Edge has the whole package (including server and client) if I understand correctly.
Link to comment
Share on other sites

TortoiseSVN is not an SVN "server" in the sense that you can't remotely extract stuff from it by default.However, an SVN repository is merely a collection of (special) files - files, which TortoiseSVN is able to create. It simply is unable to serve them over a network. So with TortoiseSVN, you do have a client and server, but have the client be on the same machine as the server.But if you're going to push a copy of the repository to a backup server, you don't need to have a "server" in that sense. If you start needing it, there are Apache modules (I'm not sure if they were bundled with TortoiseSVN...) and other binaries that allow remote fetching of repository managed files. In that scenario, the remote clients will have TortoiseSVN as well, but instead of using the "Create repository here" option, they'll "checkout" the repository from the server machine.

Link to comment
Share on other sites

But if you're going to push a copy of the repository to a backup server, you don't need to have a "server" in that sense. If you start needing it, there are Apache modules (I'm not sure if they were bundled with TortoiseSVN...) and other binaries that allow remote fetching of repository managed files. In that scenario, the remote clients will have TortoiseSVN as well, but instead of using the "Create repository here" option, they'll "checkout" the repository.
Ok, I'm a little confused. Why do I not need a server? Isn't the VCS server what tracks changes and controls the branching/merging? EDIT: Actually, I think I just answered my own question. I reread your post, and I see you are referring to "server" as something that allows other users to check out the code. Which Tortoise won't do. But, Tortoise is a VCS server in the sense that it still tracks history and does branching and merging. Is this correct? Edited by ShadowMage
Link to comment
Share on other sites

Ok, I'm a little confused. Why do I not need a server? Isn't the VCS server what tracks changes and controls the branching/merging?
Yes, but like I said, this "server" is actually a collection of special files, not a constantly running binary program (i.e. it is NOT in the style of MySQL or Apache). TortoiseSVN can create the initial empty version of these files => You don't need anything beyond TortoiseSVN if your "server" is on the same machine as TortoiseSVN.
Link to comment
Share on other sites

Yes, but like I said, this "server" is actually a collection of special files, not a constantly running binary program (i.e. it is NOT in the style of MySQL or Apache). TortoiseSVN can create the initial empty version of these files => You don't need anything beyond TortoiseSVN if your "server" is on the same machine as TortoiseSVN.
I think I understand. So for now, I'll just use Tortoise and maybe in the future, if things work out, we can install Subversion Edge (or some other VCS) on an actual server. Thanks for all the help guys.
Link to comment
Share on other sites

Well, just thought I'd pop in and let everyone know how it went. I just installed TortoiseSVN on my local workstation and I wrote a simple batch script as a backup system. The batch runs daily via Scheduled Tasks in Windows, and dumps the repository to our network, where it gets backed up by our regular nightly backups. Tortoise itself is actually far simpler to use than I expected. It fits my requirements perfectly, too. (Thanks boen, for the recommendation! :good:) I am able to create repositories and do all the branching/merging/modifying/tagging right on my local workstation. Since I am (currently) the only developer, this solution works perfectly. Now the question: :PWhat is the common naming convention for creating branches?

Link to comment
Share on other sites

SVN repos usually have the form of having folders called "branches", "tags" and "trunk" at their root, and then go from there."tags" is supposed to contain your code at certain deployed versions, and a common naming convention is for each folder in "tags" to reflect the version (number) itself."trunk" is supposed to be the latest, bleeding edge, yet to introduce to the outside world version. Nothing to name there (since it's only one version, there's no need for subfolders and naming conventions about them).And as for "branches"... that one depends on the kind of project... some developers use it for experimental modules (each name reflects the module) that would eventually be merged with the trunk, while others prefer for branches to be a kind of trunk for modules, while trunk itself contains the glue for all branches.

Tortoise itself is actually far simpler to use than I expected.
Exactly what I thought the first time I used it :P .Important note (so that you don't suffer like I did after I "relaxed"): Rename ONLY with TortoiseSVN's rename command. Forget the Windows equivalent, and given that some IDEs, despite being SVN aware, mess up, avoid renaming from them too. If you don't do that, you may have to re-checkout your code (i.e. delete your code folder, and in a new empty folder, do a "SVN checkout"), which in turn means losing any uncommitted changes.
Link to comment
Share on other sites

Now the question: :PWhat is the common naming convention for creating branches?
I would recommend reading SVN book, in particular the first 4 chapters.http://svnbook.red-bean.com/ Just expand, the trunk is the main line of development and is where all active development will be committed. You create branches to diverge to do some work you want to be able to work solo on or if it touches a lot of pages and you don't want to block other people's development. You can also create a branch say if you need to maintain a 1.0 version of software while also working on a 2.0 version. (2.0 would be ongoing in the trunk). You can merge your side branches back into the trunk once you've tested it, or merge stuff from the trunk into an ongoing branch release. (like a bug fix in 2.0 that should also be applied to 1.0). Like boen said, tags are meant to act as snapshots of your code, typically when creating a version release, like 1.0, 1.1, 2.2, etc. These should never be touched after they are tagged.
Link to comment
Share on other sites

I understand the concepts of the trunk and what tags and branches are for. I was asking about naming conventions for the branches themselves. Like all the examples I've seen in the TortoiseSVN documentation name the branches something like "V 1.2.x" but to me that doesn't make much sense. I don't know what "V 1.2.x" means in terms of what feature/fix the branch is implementing. To me, it would make more sense to name it something that reflects the feature/fix it is implementing, which I think is what boen was referring to regarding the modules. I was just wondering what the commonly accepted conventions were.

Important note (so that you don't suffer like I did after I "relaxed"): Rename ONLY with TortoiseSVN's rename command. Forget the Windows equivalent, and given that some IDEs, despite being SVN aware, mess up, avoid renaming from them too. If you don't do that, you may have to re-checkout your code (i.e. delete your code folder, and in a new empty folder, do a "SVN checkout"), which in turn means losing any uncommitted changes.
Thanks for the tip! ^_^ I'll have to try to remember that.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...