Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm going to take your chart and reorganize it a bit:</p> <pre><code> /-----gamma-----/(3)----------&gt; / / /----beta---/(1)---/(2)--/---beta--------/--\ / / / \ /------------alpha--/------/---\ \ / \ \ ------------trunk--------------------(a)----------------------(b)------------------&gt; </code></pre> <p>First, remove <code>trunk</code>, since you're not using it. Yes, you're merging back into the trunk, but you never take code out of it. Instead, <code>beta</code> comes from <code>alpha</code> and <code>gamma</code> comes from <code>beta</code>. Might as well save yourself all that effort merging back into a code line you never really use:</p> <pre><code> /-----gamma-----/(3)----------&gt; / / /----beta---/(1)---/(2)--/---beta--------/ / / / /------------alpha--/------/ / trunk </code></pre> <p>Now, let's straighten out your chart, so that the main development line is nice and straight:</p> <pre><code>trunk-alpha-------beta-----------------------gamma--------------------------&gt; \ / / \ / \---alpha-/------/ \---beta-------/ </code></pre> <p>And, finally flip over everything...</p> <pre><code> /-alpha-\-----\ /--beta-------\ / \ \ / \ trunk------/--(beta)---\-----\--------/-(gamma)---------\------(gamma)--------&gt; </code></pre> <p>There's your trunk!</p> <p>I know what you're doing. You're not coding on trunk because trunk is suppose to represent your release. In your original diagram, there are two versions on trunk. Point (a) where you merge branch alpha back to trunk, and Point (b) where you merge branch beta back to trunk. This represents your Release alpha and Release beta.</p> <p>However, that's what tags are for! You make a tag on a release, and your tag now represents your release. And, it's better because a tag preserves the history of your file.</p> <p>Let's say you go to your trunk at Point (b) and take a log of a particular file. You see the file at Point (b) and you see another version at Point (a). But, you have no idea how that file was changed between point (a) and point (b). In fact, you don't even know who's release responsible for a particular change.</p> <p>However, if you did a tag off the branch instead of merging your code back to trunk, you'd see the entire history of that file all the back to the very first version of the file. Subversion's log command (if you don't use the <code>--stop-on-copy</code> switch) will take you from the tag down to branch beta and back to trunk.</p> <p>Ah, you say, but how can I see the differences between release alpha and release beta? In my scheme, I can look at the history of the trunk!</p> <p>However, if you need to see all the changes between one release and another, you could easily just do a diff between two tags. And, sine they're tags, it's much easier to find the actual release version instead of trying to figure out which version on trunk represents your which release.</p> <p>So, you do have a trunk, but you just don't call it that.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs trunk needed in multiversion projects
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USDavid W.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs trunk needed in multiversion projects
      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. COWe cannot develop directly in the trunk because the release order of the different product versions can change by client request. The moment I have time I'll do a _graphic_ with a possible trunk-centric schema using your suggestions.
      singulars
      1. PO
      1. USDiego F. Durán
    2. COI will try to redesign the branching strategy so the trunk become the real trunk. Thanks.
      singulars
      1. PO
      1. USDiego F. Durán
 

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