Any Know of a GitHub / BitBucket API Wrapper Component?
Any Know of a GitHub / BitBucket API Wrapper Component?
Can anyone recommend a GitHub or BitBucket API wrapper component. I've found this link to GitForDelphi. This may be all that's available but I'd prefer a native component without a DLL if at all possible. Thanks - Steve
https://github.com/libgit2/GitForDelphi
Can anyone recommend a GitHub or BitBucket API wrapper component. I've found this link to GitForDelphi. This may be all that's available but I'd prefer a native component without a DLL if at all possible. Thanks - Steve
https://github.com/libgit2/GitForDelphi
I guess you mean you want to talk to git, right?
ReplyDeleteProbably in Version Insight Plus in that case:
http://sourceforge.net/p/radstudioverins/code/HEAD/tree/branches/git-hg/gitide/
However in all cases you would need git itself. What are you trying to achieve anyway?
http://docwiki.embarcadero.com/RADStudio/XE7/en/What%27s_New_in_Delphi_and_C%2B%2BBuilder_XE7#Git_Version_Control_System_Integrated_in_the_IDE
ReplyDeleteLars Fosdal thanks Lars but I'm wanting to talk to Git in my application
ReplyDeleteStefan Glienke Interesting link - thanks!
ReplyDeleteI'm wanting to test whether or not I can use Git as a customer assignment control system. So imagine a company has xxx thousand customers, each assigned to a sales rep. These relationships change over time and need to be tracked. Also you might like to go back to the a previous date to see who was responsible for a customer last year. So I'd like to be able to roll back the assignments. It struck me that I could possibly use Git or BitBucket to do this.
A DVCS (git or hg) sounds like the wrong tool for the job. I would look at a database with record versioning features, or roll your own versioning scheme in the database. This is not an uncommon, nor difficult to implement, database requirement.
ReplyDeleteI agree with Kevin Powick . One popular approach is to have a history table for each "live" table. Anytime data is changed in the "live" table the previous value is stored as another entry in the history table with a date stamp or version number. This would likely be enforced using triggers.
ReplyDeleteThe simplest solution would be to save an exact duplicate of the record just prior to being changed. This makes it easy to see exactly what the state of the "live" table was at a particular version.
It can be taken a step further by only storing deltas( only the columns that actually changed) in the history table. Many databases support sparse columns (optimized for nulls). This saves a lot of space at the expense of performance when retrieving historical data. It's also more complicated than simply saving a snapshot of the entire record because to view an old version at it would have appeared at a particular version you'd have to reconstruct it by starting at with the live version and applying changes in reverse order until you get to the version you've selected.
In either case the "live" table remains responsive to every day queries instead of getting bogged down due to ever increasing number of historical records.