backend data base

[Joerg F. Wittenberger]

> [btw, did you omit CC: to the dev list on purpose?]

Not at all.  My mail setup was messed up once, and I did not come
around to restore the certificates.  So I'm mailing via ssh/emacs
while I receive via evolution.  Cuting&pasting my way.  Not exactly
recommented. :-/

I added the list back here.  For reference I leave all of the old
message cited.

> Joerg F. Wittenberger wrote:
> > Strastwoijtje Vlad,
> >   
> 
> :-)

I'd about the only words I recall.  Except for "eto okno", which was
the first sentence in school.  about 30 yrs ago.

> >> Well, yes and no. We do not [yet] depend specifically on the merge 
> >> functionality of Subversion, but use commits/checkouts during
> >> operation.
> >>     
> >
> > So, sorry, I did not get that completely: (simplified) case A: an
> > issue is a file where state is encoded in certain fields (mail
> > header
> > format I recall) and the commit/checkout will patch this file/state.
> > BTW: I would expect problems, if Bob changes state and so does Carol
> > (if
> > their changes are in conflict; let's say Bob assigns it to Fred
> > while
> > Carol wants Barny to take care).  Case B: an issue file is either a
> > journal file, which is only appended to or it's a directory, so the
> > sync is much simpler.  A or B?
> >   
> 
> It's more of case B. Each issue is a directory, containing "comments", 
> where each comment is a delta of issue headers plus some text. So to
> get 
> the current state of the issue you need to apply all the deltas in 
> order. Thus the files are not merged, they only get added to the 
> directory. You can look at our live issue database, for example, here:
> 
> http://svn.xiolabs.com/ditrack/issues/data/i123/
> 
> As for conflicting changes, Subversion doesn't allow committing
> changes 
> to out-of-date objects. So in your scenario one of the users will get
> a 
> commit error. DITrack doesn't handle such errors yet.

That's not a bad situation to start from.  Looks as if all we had to
do was catching new files and put them up.  That's not svn specific at
all.  Disallowing changes to old objects, btw, is one of the stronger
parts on Askemos (some have called this "values oriented programming"
- file alike objects are never changed but replaces).

> > In any case: I take you for (at least): "it works with svn right
> > now,
> > because we need it for svn, but any other version control system
> > would
> > do".  If that's correct, I'd love to see ditrack evolving towards
> > backend agnostic.  (How much and what kind of commitment this little
> > love will bring about, that's what I want to find out.)
> >   
> 
> There are certain assumptions on the backend though. For example, the 
> one that I've outlined in the previous paragraph. Unfortunately I
> don't 
> have this listed anywhere; having that available would be a worthy 
> matter though.
> 
> > Beeing backend agnostic would be a fat plus for DITrack, IMHO.  The
> > current proliferation of version control systems put the free sw
> > world
> > in a state, where those good old days are over when you could get a
> > look at any project by typing this overly familar cvs command line.
> > Now you need to find out, which vc system they use and get that
> > installed first.  That's an entry barrier, which is even worse for
> > the
> > projects themself, because deciding on a vc system is already hard
> > and
> > needs to be done long before you've learned the needs of your
> > specific
> > project (after all, it's just started).  Bundling the issue tracking
> > with a particular vc system makes the situation even worse.  How to
> > you ever change for the better without a big bang - which never
> > works.
> >   
> 
> Well, I would really be happy to see DITrack working with different 
> backends. However, it's more of a resource management issue, rather
> than 
> a technical or ideological one. We just don't have enough resources to 
> design the feature, write the glue code, test, debug, support and 
> maintain it.
> 
> Having a reasonably stable system working with a single backend is
> what we are doing now. Especially taking into account that
> Subversion is becoming a mainstream, at least in the open source
> world.

Fairly enough and about the route I'd suggest.

What we could do, if we where to jump ship:

1.) We (here) would start using ditrack for askemos kernel
  development, that's basically 2-3 users.  Via svn.  We'd gain
  experience.
2.) You document the backend assumtions and we both locate the best
  API to plug into in the ditrack code.
3.) We add a second backend.
4.) We move the Application development to ditrack.  Beware: this adds
  users from at least 4 more open source companies.

The plus side of such a road map was, if we could make it formal and
"innovative" enough, we might be able to assure some govt. funding.
Innovative enough is not that hard (we'Ve done it before).  The
formula is: X is not new, but X in a tamper proofed P2P environment
is.  With X=issue tracking, we could easily explain why there's a need
for going tamper proofed: Just don't use it for free software but for
paid things.

(That was my yesterdays literature: a new funding programm.  European
and world wide cooperations are beeing seen there as a plus.  Well,
maybe I'm a bit overly enthusiastic here.)

> > Real world example: when the Chicken project decided on a tracking
> > system, they choose track (basically disabling all bundled
> > features like the wiki).  I know Felix a bit.  He would certainly
> > have loved to have a command line something working right within
> > his version control system.  "darcs".
> >   
> 
> Yes, I understand.
> 
> > So, I feel DITrack would gain much utility, if it was agnostic on
> > the backend.  I'd propose to go all the way to let the user
> > provide a commit/checkout command line or python class for the job
> > on the command line (and keep it in the working copy of the issue
> > data base).
> >   
> 
> I agree with you on this.
> 
> >   
> >> I think it's relatively easy to make DITrack work with plain
> >> directory tree structure but it's not the direction we are
> >> currently heading.
> >>     
> >
> > That's great news.  Let alone you don't head that way, if you could
> > help us paving this road, we might do the bulk work.
> >   
> 
> Well, if you feel you have enough driving force, we can start
> thinking about abstracting out the working copy access API. The
> first thing to do is, I believe, having a list of requirements for
> the backend.

See above, I should have read it all before starting to answer. ;-)

Yes, that list would be, what we need first.

> >> Do you have any particular backend in mind?
> >>     
> >
> > Yes, sure.  I'm the main author of askemos.org.  That's kind of a
> > p2p object/document data base.  We focus on forge proofed systems
> > by mutual audit of all transactions.
> >
> > Right now Askemos doesn't give much besides an interpreter core, a
> > set of language buildings tools (parser generator) and a few
> > example languages: Scheme, a Wiki and some incomplete XSLT.  CGI
> > exits are possible, but are sort of hard, since
> > http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/WhatIsTime
> > and what it a file actually?
> >
> > To solve the latter question, we tought it to speak WebDAV.  And
> > that's the backend I have in mind.  I'd like to check those issues
> > into a Askemos network. http://www.softeyes.net/AskemosNetwork
> >   
> 
> Hmm, interesting. Actually, I was looking at WebDAV recently, though
> I'm not familiar with that at all.
> 
> 
> [skipped]
> 
> >>> c) If the latter, is there something like a
> >>> documented/documentable API, which I would have to adhere to, if
> >>> I wanted to plug a different backend in?
> >>>   
> >>>       
> >> Hmm, the API is there but it's for internal use and I'm not sure
> >> how much it's suited for another backend. You can try looking at
> >> the SVN.py module of DITrack.
> >>     
> >
> > I've seen that one.  But I have not been able to deduce, how
> > specific the behavior of svn is expected.
> >
> > Sure, this ought to be an internal API.  But if there could be a
> > block comment saying approximately "we need commit+checkout and
> > the need to diff+patch like this.....at minimum", then I'd feel
> > better prepared to add alternative backends.
> >   
> 
> Yeah. That code is kinda mess, since we are just taking off. :-)
> 
> >> Can you share you needs/requirements why you would like to have
> >> such a functionality?
> >>     
> >
> > Because I want to have an issue tracking system for the Askemos
> > project.  And because I specifically do not want to depend on svn
> > (which we currently use for vc).
> >   
> 
> Ok, hope my answers help.

It does.  Let's see, what we can work out.

> 
> -- 
> Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com
> 
> 
> 
-- 
softeyes.net - Softeyes GmbH - Pf. 100318 - 01073 Dresden
Geschaeftsfuehrer Joerg Wittenberger; AG Dresden HR B23075