also sprach Thomas Koch <[email protected]> [2010.04.12.1538 +0200]: > I started a prototype in perl yesterday, but it still needs some hours. I'm > also new to perl so I could need a hand of a perl expert. If you've time, I'd > also be glad to meet for a hacking session. > Do you propose a more suitable language for this tool?
I'd use a language you know. If Perl is new to you, then you're in for a very rough ride. I also think Perl is for text-processing, but that's just me. > The merge commits do not intend to replace .topdeps. The intend of the merges > is solely to not loose commits. .topdeps is replaced by the file "branches" > shown in my blogpost. Okay, so no real benefit because to me it doesn't matter where the file is stored. I was hoping that you'd encode this information into the DAG. > > 3. It seems to me that you are proposing to store meta information > > in plain files in meta branches (cf. .topdeps). If at all > > possible, I'd say we should avoid touching the worktree > > altogether, but to design a protocol by which all the information > > we need is kept in the Git DAG and its objects. > The worktree won't be touched by my proposal. What makes you think > that? All changes to the patchset's meta branches are done by the > toolchain in the background without touching the worktree. I was thinking the worktree of the meta branch, i.e. the branches file. > I've actually started my prototype by copying code from > pristine-tar. All changes to the pristine-tar branch are made in > a temporary directory outside the worktree. Okay, but pristine-tar needs to store non-VCS information, so it makes sense for that tool. I'd really prefer to find a way to encode the information we need for packaging in the tool itself, if at all possible. > > 4. Rather than a meta branch, if we had a means to store and update > > information for each branch, we could solve the problem and store > > .topmsg, as well as the top-bases/* pointer in there. > > A rudimentary implementation might be using Git notes, e.g.: walk > > up the ancestry until you find a specially-formatted Git note, > > and use that as branch meta data store. If the data change, then > > write a new note to the top-most commit. > I'm not up to date about GIT notes. Could you point me to a description? As > far as I've seen, GIT notes is still experimental? Are GIT notes of existing > commits immutable? That would be required to make sure history won't get lost > or modified. man git-notes No, the notes are not immutable, it seems. The question is whether the data to be stored therein are worth tracking. > > 5. It occurs to me that what we want to implement somehow should > > get rid of .top* files and top-bases/*, and instead allow us to > > track "commits" at a much higher level. E.g. a branch creation > > is a commit, updating feature branches is a commit (I see no > > reason to allow updating of single feature branches > > independently, but would say either all or none), integrating > > feature branches is a commit. The way to represent that might be > > using a meta hierarchy with the merge commits you suggest, but > > which also keep ancestry. > Sorry, but I believe you think way to abstract. What I like about > my proposal is, that it only stores a few bytes of meta > informations additional to a plain, regular, unspectacular GIT > repository. I see the benefit in that, but I am not sure we couldn't take this further. I'll have to wait for your reference implementation though. > > 6. One of the main issues I have with TopGit is that it's not really > > possible to consistently tag a release with all its branches. > > E.g. you need to tag all branches, and all top-bases at the time > > of the TopGit tag, which appears brittle itself. If indeed we can > > find a method where a single commit represents the entire state > > of a tree+feature branches at a time, and one could generate all > > kinds of patch formats from it, and even fork the tree with all > > feature branches from this point, then that would be splendid. > I guess so. This is one of the main design goals beside the > ability to have multiple independent patchsets in the same > repository. Are you suggesting that the fork of a patchset becomes its own patchset without shared ancestry of the original? -- .''`. martin f. krafft <[email protected]> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "never attribute to malice what can be adequately explained by incompetence." -- mark twain
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
