We will be moving to GitHub
Marko Rauhamaa
marko at pacujo.net
Mon Jan 4 06:28:57 EST 2016
More information about the Python-list mailing list
Mon Jan 4 06:28:57 EST 2016
- Previous message (by thread): We will be moving to GitHub
- Next message (by thread): We will be moving to GitHub
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
m <mvoicem at 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
- Previous message (by thread): We will be moving to GitHub
- Next message (by thread): We will be moving to GitHub
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list