notes/EuroOSCON-2005-vc-bof.txt

   1     Notes from Version Control BOF (Tuesday, 18 Oct, EuroOSCON 2005)
   2     ================================================================
   3
   4 We didn't have a very broad range of systems: most people used SVN or
   5 CVS, plus a scattering of other systems (3 SVK users, a couple of P4s,
   6 an MKS, and a PVCS).
   7
   8 Since we already knew CVS's problems, we gathered complaints about
   9 Subversion, and some information about different groups' general VC
  10 methodologies.  See the end of this file for a list of attendees.
  11
  12 Subversion Complaints:
  13 ----------------------
  14
  15 * Lack of easy merging.  One wants to type "svn merge SRC DST", but
  16   instead, one must type "svn merge -rX:Y URL WC".  Why can't the DST
  17   just remember what has been merged from that SRC before and DTRT?
  18
  19   For that matter, why can't branches remember where they come from,
  20   so one could just type "svn merge SRC" and it'd know the DST?
  21
  22   Note that SVK does all this.
  23
  24   [gstein: shouldn't that be "svn merge DST"? you're merging *into*
  25   the destination using a known SRC. and DST might just be "."
  26
  27   [kfogel: Well, I'm not sure, it could work both ways, right?  That
  28   is, maybe you want to feed a branch's changes back into its trunk,
  29   or maybe you want to pull trunk changes out into a branch.
  30   Grammatically the argument could be the subject or object, I don't
  31   feel like either way is inherently more intuitive.  Which may mean
  32   this syntax is too ambiguous to use...]
  33
  34   [fwiemann: So why not add new commands, "push" and "pull"?]
  35
  36 * One person mentioned pulling (pushing?) trunk changes to multiple
  37   branches, a sort of "find my descendants and do THIS to them"
  38   operation.  Some more thoughts: it would be nice to be able to do
  39   this to
  40
  41   - All branches descending from the LoD ("line of development")
  42     that contains the change in question
  43   - Branches selected by inclusion
  44   - Branches selected by exclusion
  45
  46   This person also said they do cherry-picking of changes sometimes;
  47   wish we'd had time to drill down on that a bit more.
  48
  49 * Someone mentioned it would be nice to be able to commit from a trunk
  50   working copy directly into a branch.
  51
  52   [gstein: isn't this just "svn cp . http://.../branches/newbranch" ?]
  53
  54   [kfogel: Ah, yes, right, in fact we even said so at the meeting.
  55   That combined with 'svn revert' gets the desired feature.  Unless
  56   the user actually wanted to commit changes from a trunk wc into an
  57   existing branch... but that would involve perilous auto-merging.]
  58
  59   [fwiemann: Then the branch starts out with changes, so that the
  60   branch point to diff/merge against is the trunk in the previous
  61   revision, which complicates things a little because we cannot type
  62   "svn diff -r123:HEAD mybranch".  Not a major problem, though.]
  63
  64 * Offline commits.  A lot of people wanted these, mainly, it seemed,
  65   as a way of cleanly storing up commits until they can get back
  66   online again.  It's important that they be real commits, not just
  67   patch files, because the successive commits might depend on each
  68   other.
  69
  70 * The One-File-In-Many-Branches Problem.  We hand-waved a bit about
  71   what this means exactly, but I'm pretty sure it was the feature of
  72   having files (or perhaps even whole directories?) that follow one
  73   LoD but are visible from many LoD.  In other words, you create a
  74   branch, but mostly the files on the branch are really the same
  75   entities as they are on trunk, except for a few files that you
  76   designate as being "hard branched" (perhaps this designation happens
  77   automatically when you modify something).
  78
  79   This is apparently similar to p4 "views".  Can someone confirm this?
  80
  81   [gstein: p4 client specs can assemble a wc from many locations, much
  82   like you can have a multi-source wc in svn. I'm not familiar with a
  83   "view", but I'm guessing the implication is something that many
  84   developers can share to create their client spec. Wouldn't this be
  85   like an svn:external that pulls together all the various bits? or
  86   maybe use some kind of repos-side symlink.]
  87
  88   [jackr: ClearCase "view" is the sum of a working copy and a
  89   "configuration specification," which means that each WC can
  90   have a separate configuration.  In principal, each file and
  91   directory can come from a completely different branch, tag, or
  92   version; in practice, of course, most cspecs take most files
  93   from the same source.  But it's quite common to have
  94   'components' in the working set, and have each component
  95   follow a different branch.  We might have a RELEASE1 branche,
  96   nearly ready to ship, and a RELEASE2 branch that's still a
  97   long way from release.  You might be working on a RELEASE2
  98   feature, and so your cspec picks your component from the
  99   RELEASE2 branch.  But other components haven't started on
 100   RELEASE2 yet; you pick them from the RELEASE1 branch, and are
 101   assured that you're building and testing against their latest
 102   (integrate early, integrate often).]
 103
 104 * Subversion has no way to answer "What branches/tags is this version
 105   of this file present in?"  This is especially important for software
 106   producers who have to support releases for a long time.  When they
 107   discover that a given bug is present in, say, r325 of foo.c, they
 108   need a way to ask what releases (i.e., what tags) that exact entity
 109   (i.e., "node revision") is present in, because those releases will
 110   also have the bug!
 111
 112   CVS can do this, by virtue of RCS format.  ClearCase can too, I
 113   believe.  Subversion certainly could do it; in general, we need to
 114   think about how to make these kinds of reports and queries easier.
 115   If we ever get serious about switching to an SQL back end for SVN,
 116   this would be a perfect test problem to see if our design is on the
 117   right track.
 118
 119   Gervase demonstrated Bonsai doing this, a CVS tree viewing tool
 120   which, as he says, "is very cool but not well documented and only
 121   mozilla.org seems to use".  Since  it views CVS, this sort of
 122   calculation is easy for it.
 123
 124   It was pointed out by Axel Hecht that due to the requirements of
 125   l10n work, Mozilla actually uses this feature "at least once per
 126   week".
 127
 128 * Branching subdirectories in SVN is not intuitive...
 129
 130 * ...which means this is probably a good time to bring up 'mkdir -p'
 131   (automatically create parent directories; see issue #1776), as well
 132   as 'rm -k/--keep' (only "unversion" files, do not delete the working
 133   files), and 'diff -s/--summary' (status-like diff output; see issue
 134   #2015), all of which were desired by clkao.
 135
 136   [Question: Did someone start on a patch for 'svn diff --summary'
 137   recently?  I think I may have seen that on the dev@ list... Yes.
 138   In http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=108496,
 139   Peter Lundblad says: "The API part of this is already implemented
 140   some time ago. So, it is quite low-hanging to do the cmdline GUI
 141   part."  -kfogel]
 142
 143 * Smart patch format.  A patch format that can represent every kind of
 144   transformation that could be transmitted by 'svn update'.  We should
 145   make sure to be compatible with SVK when we do this; clkao and
 146   kfogel have already discussed this, and there's been some talk on
 147   dev@subversion.tigris.org too.
 148
 149 Comments from projects that switched from CVS to SVN:
 150 -----------------------------------------------------
 151
 152 * The w.c. space penalty is a real issue for large projects.  Disk
 153   space is not as cheap as we thought, those .svn/text-base/* files
 154   hurt.  See http://subversion.tigris.org/issues/show_bug.cgi?id=525.
 155
 156   [gerv: Random thought - if you can't easily do copy-on-write, could
 157   you perhaps share text-base files by hard-linking between multiple
 158   checkouts of the same tree (which is where this problem normally
 159   hits hardest.) Yes, OK, there are scary thoughts there about trees
 160   no longer being independent of each other...]
 161
 162 * Hosting the repository and migrating the user base were issues for
 163   at least one open source project (Docutils, reported by Felix
 164   Wiemann):
 165
 166   - There weren't many free Subversion hosting services that offer
 167     enough features; see
 168     <http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/felixwiemann/subversion.txt?rev=3080>
 169     for a list of requirements we had.  We chose BerliOS, which is
 170     scary though because they provide little support.
 171
 172     Tigris (recently?) started to offer free Subversion hosting as
 173     well, but it's a bit difficult to find that out from their web
 174     site, and it isn't listed in the Subversion Project Links.
 175
 176   - Repository migration went flawless with cvs2svn (except for some
 177     binary files being garbled).
 178
 179     Since there seemed to be some interest in that: We even could've
 180     migrated the repository in several passes (migrating one part at a
 181     time) by converting a part and then dumping the resulting
 182     repository.  Note however that commit dates would get out-of-order
 183     (non-chronological) so that -r{DATE} doesn't work anymore.
 184
 185   - Regarding migrating the user base: There's some natural tension to
 186     switch the SCM because developers have to install a new tool.
 187     That seemed acceptably easy in this case, however.  Also, all
 188     developers have to manually re-register at the new site (BerliOS)
 189     to get access to the repository.  But overall that part of the
 190     migration went quite painless.
 191
 192 * One group rejected BitKeeper for UI reasons.
 193
 194 * One person commented that distributed systems don't address
 195   migration concerns.  Also, they don't clearly say how to implement a
 196   centralized-style system on top of the decentralized substrate.  In
 197   general, they need more process guidance.  Subversion probably gets
 198   off easy here because it takes advantage of a process people already
 199   know, because they used CVS before.
 200
 201 * Also, the distributed systems don't have GUI tools, at least not as
 202   many so far.  I (kfogel) took this comment as indicating that the
 203   overall "tool ecosystem" is an important part of the decision for a
 204   lot of groups.
 205
 206 * GIT and BK have GUIs that display topology.  I think ClearCase does
 207   too, btw.  Wish we'd had time to go into more detail about exactly
 208   how these viewers are used, and how often.  Anyone care to comment?
 209
 210   [jackr: Yes, ClearCase has a graphical topology viewer.  Mixed
 211    success.  Tends to become absolutely crucial to managing
 212    branches at a certain level of complexity; tends to destroy
 213    the server with its server-side computations at about "that
 214    level plus epsilon".  Example: parallel development of some
 215    new feature, occasional ladder-merges from trunk out to that
 216    branch keep it in sync.  Just before delivering the work to
 217    the world on trunk, you wonder "what's happened since my last
 218    merge-out?"
 219
 220    Another example: we branch releases off trunk just before
 221    release, for final stabilization. Then we create patches on
 222    that same branch.  Sometimes, we fork a new branch for a
 223    maintenance release, sometimes we just extend the existing
 224    branch.  Now, you're assigned to provide an urgent patch to
 225    some old maintenance release: quick: do you use the parent
 226    release branch, or is there a maintenance branch?  In SVN,
 227    you may be able to handle this with a listing of branches/
 228    and some knowledge of branch-naming strategies, but in
 229    ClearCase there's nothing quite analogous.]
 230
 231 Attendees:
 232 ----------
 233
 234 * Gervase Markham <gerv {_at_} mozilla.org>
 235   Large CVS repository (mozilla), small SVN (personal)
 236
 237 * Chia-Liang Gao <clkao {_at_} clkao.org>
 238   SVK, SVN, p4, CVS
 239
 240 * Ottone Grasso <ottone.grasso {_at_} tilab.com>
 241   SVN
 242
 243 * Mauro Borghi <mauro.borghi {_at_} telecomitalia.it>
 244   Small CVS and SVN
 245
 246 * Axel Hecht <axel {_at_} mozilla.com>
 247   1 SVN + N CVS
 248
 249 * Felix Wiemann <felix.wiemann {_at_} ososo.de>
 250   SVN, CVS, MKS
 251
 252 * Greg Stein <gstein {_at_} google.com>
 253   CVS, SVN, p4
 254
 255 * John Viega <viega {_at_} securesoftware.com>
 256   Didn't say.
 257
 258 * Brian Fitzpatrick <fitz {_at_} google.com>
 259   CVS, SVN, p4
 260
 261 * Sander Striker <striker {_at_} apache.org>
 262   SVN, CVS
 263
 264 * Stefan Taxhet <stefan.taxhet {_at_} sun.com>
 265   CVS (OpenOffice.org)
 266
 267 * Christian Neeb <chneeb {_at_} gmx.net>
 268   CVS, PVCS
 269
 270 * Arjen Schwarz <arjen.schwarz {_at_} gmail.com>
 271   No version control.
 272
 273 * Erik Hülsmann <ehuels {_at_} gmail.com>
 274   SVN, CVS
 275
 276 * Dobrica Pavlinusic <dpavlin {_at_} rot13.org>
 277   Legacy CVS, SVN, SVK, svn2cvs.pl
 278
 279 * Gonçalo Afonso <gafonso {_at_} gmail.com>
 280   CVS
 281
 282 * David Ramalho <dramalho {_at_} blackorange.pt>
 283   CVS, SVN, SVK
 284
 285 * Karl Fogel <kfogel {_at_} collab.net>
 286   SVN, CVS
 287
 288 Also, Jack Repenning <jrepenning {_at_} collab.net> did not attend,
 289 but read the notes and added some comments; search for "jackr".
 290
 291 ## Local Variables:
 292 ## coding:utf-8
 293 ## End:
 294 ## vim:encoding=utf8