"Daniel 'NebuchadnezzaR' Dehennin" <[EMAIL PROTECTED]>
writes:
> Hello,
>
> I do not make many test with bzr but do we have the problem of merging
> only some merge between people, I explain:
>
> - A made a change
> - B merge A
> - A merge the merge of B
> - B merge the merge of A of the merge of B
> ...
bzr allows convergence, so, the
> - A merge the merge of B
can be replace by a simple "pull" if you want to avoid this problem.
It will give A the _same_ revision as the head of B. When I say the
same, I mean not only he same content, but also the same revision
identifier, so the last step should say there's nothing to merge.
This was indeed a minor problem with the Arch model, in which two
branches never actually converge, one is always in advance of the
other by at least one patch.
> And for the development, I use a private branch to make my hack, and
> then I use baz delta to "easily" apply the changes hunk by hunk to my
^^^^^^^^^
> public branch (to avoid people seeing all the private changesets).
I don't understand what you're doing here. Do you mean "bzr" instead
of "baz"?
Do you have anything important to hide in your private branche ?
Otherwise, the way to do it is to merge your private changes into your
public branch. By doing this manually, you lose all the benefit of
using a revision control system instead of just "diff+patch".
> Maybe, this is not the good place for that but it can be interessting
> to make some recipe of "developping with DVC", with a real worl
> developpement like DVC itself:
Somewhat agree, but not completely so. With tla, we had to implement a
lot of hacks in Xtla because tla was not evolving anymore (I didn't
follow the previous developments, but after tla 1.2, the only real
evolution before Tom left was the management of spaces in filenames).
For example, the "merge assistant" which tells you which revisions
have been merged by someone else is something which isn't
Emacs-specific, and which shouldn't have been implemented in Xtla.
(Milan's comment about Xtla and Darcs was particularly interesting
about that. He said he didn't _need_ an Emacs interface to use Darcs.
Understand : tla was unusable without it ...)
The development teams of the other back-end we support today are still
active, and open to proposals, so the real work should be done there.
DVC is an interface to use decentralized VCS inside Emacs comfortably,
but not a VCS by itself.
Someone who uses DVC should be able to continue with the same
development flow if he or she decides to drop DVC. Similarly, someone
using DVC should be able to work with someone else not using it
without troubles.
In brief, DVC should not enforce any workflow, but should just make it
more comfortable (things like ediff integration give real added value
for example).
--
Matthieu
_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev
