Masatake YAMATO <[EMAIL PROTECTED]> writes: > However, I have some comments about DVC. > Just comments.
Thanks, we need comments more than code in the current development phase IMHO. > 0. Baz support > > I've found some problems in baz support of xtla-12. > In other hand, Matthieu or someone will fix a baz related bug in > dvc tree. What we should do? My proposal is that > > A. I will maintain xtla-12 main tree, > B. Other developers put "baz-dvc" in keyword of ++log when fixing a bug > about baz in dvc tree. I will merge the change to my xtla-12 main tree. > C. When fixing a bug about baz in xtla-12 tree, I will merge the fix to > MY dvc tree with keyword baz-12. Matthieu, dvc main tree maintainer will > merge the fix to the main tree. If you remove bzr-*.el and xhg-*.el from the DVC tree, you should get only a better structured Xtla. So, let's say that Xtla 1.3 is DVC without the other files. Then, you're in the common situation of maintaining a stable branch in parallel with a development branch. The only real problem is that many code moving and renaming prevent automatic merging in a part of the code. That's why I think we should concentrate the efforts on DVC, and release Xtla 1.2 as soon as possible (this doesn't prevent us from fixing bugs in 1.2.x, but it's a symbolic and relatively strong way to say that no more feature will come in the 1.2 branch). I wanted to make a simultaneous release of Bazaar 1.5 and Xtla 1.2. Perhaps we should release the 1.2 now itself, and consider that Xtla 1.3 will be a subset of DVC. > CVC - Changeset oriented unified frontend for version control system Just two points of vocubulary: Be carefull with the expression "changeset oriented" because not all modern RCS belong to that category. GNU Arch 1.x and Bazaar 1.x are changeset oriented. This means that revisions are stored as changesets against the ancestor. Many operations (merge, undo, ...) are usually done by computing a changeset, and applying it to a tree. Bazaar 2, GNU Arch 2.0 (if it ever reaches maturity), git, mercurial (not sure about the last one) are all "snapshot oriented". In Bazaar 2, for example, you do not (yet) have a notion of changeset. Each revision is stored logically as a snapshot, although the latest archive format use weaves to compress them, which gives a compact storage format, like changesets. Merge operations use 3-way merge. The input for the merge operation are: "the common ancestor", "your version", and "the merge source". Not "your version" and "the delta". I think what you meant is "version-control with atomic commits", or "tree-wide operations version control". Don't know what's the most appropriate wording. Second point, I don't like to describe DVC as a "unified frontend". I don't target a real unification, and I do want the different dvc-backends to be different, to reflect the differences (in particular the strength) of the back-end tools. > DVC - Unified frontend for distributed version control system > > What I'd like to say is CVC and DVC is different. > e.g. grand unified changeset oriented diff interface is > not part of DVC but CVC. > > So what is DVC? > I think Matthieu's bookmark and partner functions are the core > functionality of DVC layer. Only 50% agree. I made a mistake making the bookmark feature so much central. The "partner missing" feature is great, but we could have allowed a more simple M-x baz-partner-missing RET ~/path/to/local-tree RET. The bookmarks are a way to store the information, but the bookmark buffer doesn't _have_ to be the starting point for version control operations. > At first time, I tried to implement darcs backend. However, darcs and > emacs user will not join our development because we are using tla, baz > and bzr. We should use a version control system Foo for developing a > dvc backend for Foo. As the result we will get much more users and developers. > More importantly, the quality of backend will be improved. Clearly. I'm a bit frustrated myself to use baz to develop a bzr-related tool ;-). But that's not easy. What's easy is to maintain a mirror of a branch managed by another version control system. Canonical maintains an arch mirror of many CVS projects for example. The difficulty is to have a correct management of the merge history. Some people have been talking about implementing "foreign branches" into bzr. That may allow bzr users to access an arch archive for example. But that would solve the problem only for bzr users. I think we can wait a bit to consider this problem. For now, I'm still confortable with the Xtla part of DVC to develop DVC, and the TODO list is long enough, so I don't need more experience with bzr-dvc to fill it in ;-). -- Matthieu
