VsSubversion.markdown

   1 \r
   2 Svn\r
   3 ===\r
   4 \r
   5  * pro: Monotic rev numbers (though commitnumbers is better as they don't change with the whole repo)\r
   6  * pro: Cherry picking doesn't duplicate the commit\r
   7  * pro: Good/faster trac integration\r
   8  * pro: Inherently flattened branches (requires branch.name.rebase+pending preservemerges--or `pull`)\r
   9  * con: allows anti-social change hoarding of one large commit\r
  10  * con: lots of .svn meta folders (slows down Eclipse)\r
  11  * con: looses data in rename+merge scenario\r
  12  * con: allows pushing from an out-of-date working copy as long as specific files don't conflict\r
  13 \r
  14 Git\r
  15 ===\r
  16 \r
  17  * pro: index (easier to break up commits, see only conflicts during merging)\r
  18  * pro: stash (or local WIP on multiple branches without separate working copies)\r
  19  * pro: local commits\r
  20  * pro: combined diffs in gitk and commit emails\r
  21  * pro: "git diff" in conflicted merges only shows conflicts, not what merged cleanly\r
  22  * pro: safe merging (working copy is not munged, always have ORIG_HEAD or reflog)\r
  23  * pro: pre-filled-in merge commit messages (e.g. with what conflicted)\r
  24  * pro: DAG visualization (gitk)\r
  25  * pro: just one .git meta folder\r
  26  * con: requires flags/prefer-rebase script to maintain flattened branches\r
  27  * con: allows anti-social change hoarding of many small commits\r
  28  * con: no good tattoo (fixed with commitnumbers)\r
  29  * con: trac integration is slow\r
  30 \r