Integrating Version History


  1. Bootstrap is a single small executable jar that is effectively a git client that will fetch uSDLC from a GitHub.
    1. Provide an EXE wrapper for Windows – the only likely environment without Java (?)
    2. Running the bootstrap clones uSDLC and marks it as incoming only.
      1. Clones are incoming or two-way.
        1. Incoming clones updated from the master but changes are only local.
        2. Two-way will update from the master and push back to the master.
    3. The bootstrap will generate a GUID to uniquely identify this instance.
    4. The bootstrap also creates a dependent-bootstrap bootstrap jar. Run this jar anywhere. It will treat the source as master. This way you can create a dependency web without the user knowing about Git.
  2. In short you run the bootstrap on a machine and it will create a uSDLC version that will duplicates the master. This could be the GitHub source or one related to a project or organisation.
  3. uSDLC provides for disconnection tolerance – provided by Git.
    1. A notebook or thumb-drive copy will re-sync when connected.
    2. Running a bootstrap expects to find it’s master  – so they should be created just before use.
    3. After cloning the master it asks for a map of the Git web back to the first incoming only master.
    4. If a master is missing, a push to any other node will update all nodes with the same data.
    5. When a node reconnects it may have a different IP address or DNS name.
      1.  To reconnect it must walk it’s node web record looking for someone who is still there.
      2. Once one is found it is possible to rebuild the node web (under Git version control).
      3. When they need it every node will know of the new place for the reconnected node.
      4. Problems arise when using DNS instead of IP address. Sometimes an external DNS name does not translate to the correct IP interface.
  4. uSDLC generates and maintains tasks for workflow
    1. Creating a new section (paragraph) creates a new task.
    2. Task states include new, reviewed, instrumented, implemented, failing, tested, completed, rejected, conflicted and merged.
    3. A task is always owned by some one or some group. It is first owned by the creator. The creator may pass] to a team (larger group) who then allocate it to a pair to instrument (smaller group). The instrumentation pair may pass it to a developer to implement.
    4. There is a one-to-one relationship between tasks and Git branches.
    5. Workflow instructions decide how to move a branch from completed to merged.
      1. Automatic merges suite a small project.
      2. A code freeze can hold up a merge.
      3. Larger projects will have a gate-keeper who will check tasks in a completed state and control merging.
  5. Conflicts can belong to one of two groups
    1. Text files conflict when the same text changes in both branches.
    2. Binary files conflict when the two branches have changed independently.
  6. A task in conflict can’t be closed. It enters a conflict state instead until resolved.
  7. In general use, git is completely transparent.
    1. Any change to any file linked to a task is checked in on the connected branch.
    2. The system pushes changes to other nodes regularly.
    3. Completing a task will trigger a merge of task branch to a trunk.
    4. Conflicts will abort a merge and offer tools and information for manual merging.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s