m <mvoi...@gmail.com>:
> W dniu 03.01.2016 o 01:33, Marko Rauhamaa pisze:
>> Teamware didn't have to pick any of them since Teamware's commits were
>> done per individual files. The repository didn't have a commit history.
>>
>> Thus, Teamware was equivalent to Hg/Git with each file treated as an
>> independent repository.
>>
>
> It sounds like CVS.
The main problem with CVS is that these operations don't commute:
*
edit :
----+--------------+--------------->
\ \ :
\ \ :
\branch \merge :
\ \ :
v v :
+--------------+---------->
:
:
:
:
----+-------------------+---------->
\ ^ :
\ / :
\branch /merge :
\ / :
v edit / :
+---------+--------------->
:
If you look at the edited file at *, CVS reveals the merge direction in
the version history. In Teamware, you can't see afterwards, which way
the change was made ("branches" and "merges" are not recorded).
Additionally, CVS doesn't make the distinction between commits and
merges, which both Hg/Git and Teamware do. The distinction could be
emulated in CVS (as well as, say, Perforce) but very awkwardly.
> How can you be sure that your code is consistent if each of your file
> has it's own, independent history? Use tags like in CVS?
Yes, tags ("checkpoints") can be used, although I don't remember us
using them. Rather, we used distinct clones for tagging.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
