Skip to content
jcsalomon edited this page Oct 9, 2011 · 29 revisions

Authenticated vs Non-Authenticated?

Authenticated
Where to store credentials?
~/.ticgit-ng/conf
~/.gitconf
Input as CLI args

How to programatically access stored credentials in ~/.gitconf
http://programmers.stackexchange.com/questions/64570/programmatically-accessing-gitconfig/64661#64661

Bug tracker attribute comparison

Ticgit

  • title
  • body
  • assigned to
  • date bug was opened
  • unique ID
  • state
  • points
  • tags
  • comments
    --- date added
    --- author
    --- body

Github Issues

  • title
  • body
  • created at
  • gravatar ID
  • html_url
  • labels
  • number (unique ID)
  • position
  • updated at
  • user
  • votes
  • comments (numerical)
    --- gravatar_id
    --- created_at
    --- body
    --- updated_at
    --- id
    --- user (author)

Lighthouse

  • title
  • description
  • assigned to
  • milestone
  • tags
  • attachment
  • state
  • age
  • comments
    :author
    :created on
    :comment

Can dates be forged?
Is there an API?
Lighthouse let's you change the title but this would choke ticgit because everything in ticgit is hashed and thus immutable.

Bugzilla

  • product
    :component
    :version
  • milestones
  • flags (?, +, -) + (text)
  • keywords *
  • custom fields
  • votes *
  • groups
  • qa contact *
  • URL *
  • summary
  • status whiteboard
  • platform and OS
  • version
  • priority
  • severity
  • target *
  • reporter
  • cc list
  • attachments
  • dependencies *
  • additional comments
  • description

Requisite fields

  • product
  • component
  • version
  • operating sys
  • platform

* denotes field that may not exist in all bugzilla bug trackers

Standard Fields across all bug trackers

  • Title
  • Body
  • Created on
  • State
  • Label
  • Comments
    --- Date Added
    --- Author
    --- Body

Third Party Bug Tracker Integration

This section describes how to write a module to allow syncing with third party bug trackers.

Create a file in the lib/ticgit-ng/sync directory in your TicGit-ng repository with the name of your bug tracker (spaces as underscores). So for example, to create a module to sync with Google Code, it would be

ticgit/lib/ticgit-ng/sync/google_code.rb

and the module you create would be

TicGitNG::Sync::Google_Code

note that the file name must be the lowercase version of the class. This allows us to know what class to look up from the name of the file.

The class should have at least these 5 methods, index(), show(), create(), update(), destroy().

Code Arrangement

The syncing code used by ticgit to sync with other ticgit branches is kept in the base.rb file. The syncing code to sync with third party bug trackers is kept in a file named appropriately (see above) in the sync/ directory. The code that glues the third party bug tracker files together and does the actual syncing is in sync.rb

Syncing Complexities

  • It should be expected that external bug trackers won't allow us to edit comments that have been posted.
  • Since it will be possible for two separate bug trackers to contain the same bug, and for two different people to comment on the same ticket in different bug trackers, merging the two could be difficult because APIs are not likely to allow you to supply the 'date created' field (they are instead likely to use the time the comment was submitted to that bug tracker). Because of this, in order to not lose that information when syncing with other bug trackers, a way of including that needs to be devised. Currently my best idea is to simply append a "#created in BUGTRACKER\n#created on DATE\n#created by AUTHOR\n" string to the comment.
  • As per the second point, APIs may not let you supply the 'created by' field when syncing comments with external bug trackers, this info will be added in a comment ticket if necessary.
  • when syncing, make sure events are synced in the order they happened.
  • when syncing, if someone posts a comment, we sync, andthen they change their comment twice before we sync again, we lose the ability to see what was said in the second edition and only capture the first and third edition.
  • Remember to find a way of dealing with situations where someone (person1) clones someone else's (person2) repo, but doesn't keep in sync with it. Because of how comments can be edited without leaving a complete history of edits, they may lose information if a comment is edited twice and person2 has both edits but person1 only has the first and final versions of the comment. This could complicate trying to merge those two branches