Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The topic of version control systems is probably a bit too large to teach as part of a Q&amp;A site like Stack Overflow. You're certainly welcome to ask questions about them, but "can anyone tell me all I need to know about them" is probably not the right place.</p> <p>If you're interested in distributed version control systems, since you've mentioned git, you should take a look at <a href="http://hginit.com" rel="nofollow">hginit.com</a>. While the site describes <a href="http://mercurial.selenic.com" rel="nofollow">Mercurial</a>, most, if not all, holds true for git as well.</p> <p>As for the recommendation to create those folders, that depends entirely on the version control system you decide to use.</p> <p>Subversion uses folder-level "copies" to create branches. Think of it as having multiple copies of your project on disk at the same time, and that Subversion allows you to merge changes from one folder to another and keeps track of what you have merged, when, and in which direction.</p> <p>For DVCS', that isn't necessary, since branches are done in a different way, and thus you don't need those directories.</p> <p>The vocabulary you have listed can be summed up as follows (note that since I use Mercurial, I might be colored by their use in that system):</p> <ul> <li><strong>Trunk</strong> - Your main development line. If you didn't have source control, this is where you would work all the time.</li> <li><strong>Tags</strong> - A tag is a lightweight marker, think of it as a postit note, that you affix to a certain version of your project so that you later can answer the question "Hmm, I wonder what all the source files looked like when I released version 1.0"</li> <li><strong>Branches</strong> - A branch is a parallell universe copy of your project, possibly with changes. For instance, when you released that 1.0 version, you might create that tag, but you might also create a branch. Then, on trunk, you would start working towards version 2.0 or 1.1, and if you need to release a hotfix of 1.0 to fix bugs, you would then do those fixes on that 1.0 branch.</li> <li><strong>Merging</strong> - When you have multiple branches, you can ask your version control system to help you get changes done on one branch into another by merging them (the changes or the branches, this differs from system to system.)</li> <li><strong>Changeset/revision</strong> - Nearly synonymous, means a set of changes you committed at the same time. It might be to fix a particular bug, or add a particular feature. A changeset can contain changes to many files, and even new files, or removal of files no longer needed.</li> </ul> <p>The <a href="http://en.wikipedia.org/wiki/Revision_control" rel="nofollow">Wikipedia article on Revision control</a> also has quite a lot of useful information.</p> <p>The <a href="http://selenic.com/hg/help/glossary" rel="nofollow">Mercurial glossary</a> also lists a fair number of terms and their usage in Mercurial, and much of that information is true for many version control systems.</p> <hr> <p>Anyway, here's a typical (for me anyway) way to do a project.</p> <ul> <li>You create the initial project repository, with just the main branch (trunk in Subversion, default in Mercurial, master? I think in git)</li> <li>You then start working on your project, and you commit regularly, you build up a nice list of changesets</li> <li>At some point you are ready to release version 1.0, so you create that tag, and you create a branch at that point named "1.0", and then you release your software</li> <li>You then continue working, towards version 1.1 or 2.0, depending</li> <li>At some point you have a list of bugs that have been found in 1.0 by customers</li> <li>You fix those bugs in trunk/default/master, so that the next big version at least has those bugfixes, then you merge the changes back into 1.0</li> <li>When all known bugs in 1.0 have been fixed, you tag that as 1.01, and release that</li> <li>And back to work on 2.0</li> <li>When 2.0 is ready to release, you tag and branch again, etc.</li> </ul> <p>This is just one way to do it, there are many. People will tell you their preferred way if you ask them and I won't say my way is right.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to use a revision control system in general
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USLasse Vågsæther Karlsen
    1. USLasse Vågsæther Karlsen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to use a revision control system in general
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you that you took the time to answer :) I do not really search everything about version control systems that would be too much for a site like Stack Overflow ;) I just wanted to know some "basics" like the trunk tag branches thing (with other words how the development process in general goes); so something were to start "understanding" and continuing my researches regarding those systems
      singulars
      1. PO
      1. UStbolender
    2. COI've edited in a few more details. Note that there probably isn't a right way to do this, but there are plenty of bad ways to do this, the good ways are just good in different ways. I suggest you first decide if you want to use a centralized version control system or a distributed one (ie. Subversion vs. Mercurial/git), and then read up on how they each work. The devil is in the details. My advice, however, is to go with a DVCS, and since I use Mercurial, of course Mercurial is the best one there is :)
      singulars
      1. PO
      1. USLasse Vågsæther Karlsen
    3. CO"few more details" o_O. Btw, +1 for the answer itself and for mentioning mercurial as a start point.
      singulars
      1. PO
      1. USzerkms
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload