> BuGit's data storage surely looks interesting, and does not have some
> of the inconveniences git-dit has. However, the data-layout of git-dit
> also has it's perks. For example, merge-conflicts simply cannot occur
> (not counting attachments, which are not supported yet).
Indeed, merge conflicts can occur, but in almost all other case, Git's
merge algorithm should resolve the conflict satisfactorily (e.g. if
someone sets the priority to 3 and someone else sets it to 5, the merge
will give it a priority of 4; note that the same holds if 999 people
change the priority to 5 and 1 sets it to 3 and then we merge all those
1000 changes).
> If I'm reading the BuGit source correctly, replies are simply added to
> the description. If you have two concurrent replies, you end up with
> the necessity of a merge with all the associated problems.
No, replies usually have no file modifications (i.e. the text of the
reply is kept in the commit-message, just as does git-dit IIUC, tho they
can add files (attachments), but these files's names should be unique).
So such concurrent replies never cause a merge conflict.
> But the _hard_ problem of resolving conflicts of concurrent
> modifications of an issue is simply non-existent for us.
IIRC for BuGit, conflicts can only appear for "bugit reply --editdesc",
and "bugit rename", but that's inherent to the functionality offered,
AFAICT, rather than due to any kind of implementation choice.
> Btw., it never occured to us to move some metadata into the tree the
> way BuGit does. It would surely work for some classes of issues.
> But we also want to support patch-sets and for them it would
> be problematic.
By "patch set", do you mean that you want to have the ability for issues
to refer to some "candidate branch". Would you store the candidate
branch as a "parent" in the commit (if so, how do you distinguish that
parent from one that isn't a patch-set but some other reference), or
would you store them under /refs/dit/<issueid>/patchsets/<id>?
I haven't thought very much about how to deal with it in BuGit. To the
extent that I'd like to make it possible to keep the issue repository
separate from the code repository, I think I'd keep the reference to
a patch-set as a piece of text (presumably a commit-id), probably in
a file-name. This would obviously suffer from the fact that Git doesn't
get to know about this commit-id, so we have no guarantee that this
commit-id can be found in the repository (i.e. it's like
a weak-reference).
Another interesting avenue is to see how it could handle git-appraise.
Stefan
_______________________________________________
dist-bugs mailing list
[email protected]
https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
