Notes from Version Control BOF (Tuesday, 18 Oct, EuroOSCON 2005)
================================================================
We didn't have a very broad range of systems: most people used SVN or
CVS, plus a scattering of other systems (3 SVK users, a couple of P4s,
an MKS, and a PVCS).
Since we already knew CVS's problems, we gathered complaints about
Subversion, and some information about different groups' general VC
methodologies. See the end of this file for a list of attendees.
Subversion Complaints:
----------------------
* Lack of easy merging. One wants to type "svn merge SRC DST", but
instead, one must type "svn merge -rX:Y URL WC". Why can't the DST
just remember what has been merged from that SRC before and DTRT?
For that matter, why can't branches remember where they come from,
so one could just type "svn merge SRC" and it'd know the DST?
Note that SVK does all this.
[gstein: shouldn't that be "svn merge DST"? you're merging *into*
the destination using a known SRC. and DST might just be "."
[kfogel: Well, I'm not sure, it could work both ways, right? That
is, maybe you want to feed a branch's changes back into its trunk,
or maybe you want to pull trunk changes out into a branch.
Grammatically the argument could be the subject or object, I don't
feel like either way is inherently more intuitive. Which may mean
this syntax is too ambiguous to use...]
[fwiemann: So why not add new commands, "push" and "pull"?]
* One person mentioned pulling (pushing?) trunk changes to multiple
branches, a sort of "find my descendants and do THIS to them"
operation. Some more thoughts: it would be nice to be able to do
this to
- All branches descending from the LoD ("line of development")
that contains the change in question
- Branches selected by inclusion
- Branches selected by exclusion
This person also said they do cherry-picking of changes sometimes;
wish we'd had time to drill down on that a bit more.
* Someone mentioned it would be nice to be able to commit from a trunk
working copy directly into a branch.
[gstein: isn't this just "svn cp . http://.../branches/newbranch" ?]
[kfogel: Ah, yes, right, in fact we even said so at the meeting.
That combined with 'svn revert' gets the desired feature. Unless
the user actually wanted to commit changes from a trunk wc into an
existing branch... but that would involve perilous auto-merging.]
[fwiemann: Then the branch starts out with changes, so that the
branch point to diff/merge against is the trunk in the previous
revision, which complicates things a little because we cannot type
"svn diff -r123:HEAD mybranch". Not a major problem, though.]
* Offline commits. A lot of people wanted these, mainly, it seemed,
as a way of cleanly storing up commits until they can get back
online again. It's important that they be real commits, not just
patch files, because the successive commits might depend on each
other.
* The One-File-In-Many-Branches Problem. We hand-waved a bit about
what this means exactly, but I'm pretty sure it was the feature of
having files (or perhaps even whole directories?) that follow one
LoD but are visible from many LoD. In other words, you create a
branch, but mostly the files on the branch are really the same
entities as they are on trunk, except for a few files that you
designate as being "hard branched" (perhaps this designation happens
automatically when you modify something).
This is apparently similar to p4 "views". Can someone confirm this?
[gstein: p4 client specs can assemble a wc from many locations, much
like you can have a multi-source wc in svn. I'm not familiar with a
"view", but I'm guessing the implication is something that many
developers can share to create their client spec. Wouldn't this be
like an svn:external that pulls together all the various bits? or
maybe use some kind of repos-side symlink.]
[jackr: ClearCase "view" is the sum of a working copy and a
"configuration specification," which means that each WC can
have a separate configuration. In principal, each file and
directory can come from a completely different branch, tag, or
version; in practice, of course, most cspecs take most files
from the same source. But it's quite common to have
'components' in the working set, and have each component
follow a different branch. We might have a RELEASE1 branche,
nearly ready to ship, and a RELEASE2 branch that's still a
long way from release. You might be working on a RELEASE2
feature, and so your cspec picks your component from the
RELEASE2 branch. But other components haven't started on
RELEASE2 yet; you pick them from the RELEASE1 branch, and are
assured that you're building and testing against their latest
(integrate early, integrate often).]
* Subversion has no way to answer "What branches/tags is this version
of this file present in?" This is especially important for software
producers who have to support releases for a long time. When they
discover that a given bug is present in, say, r325 of foo.c, they
need a way to ask what releases (i.e., what tags) that exact entity
(i.e., "node revision") is present in, because those releases will
also have the bug!
CVS can do this, by virtue of RCS format. ClearCase can too, I
believe. Subversion certainly could do it; in general, we need to
think about how to make these kinds of reports and queries easier.
If we ever get serious about switching to an SQL back end for SVN,
this would be a perfect test problem to see if our design is on the
right track.
Gervase demonstrated Bonsai doing this, a CVS tree viewing tool
which, as he says, "is very cool but not well documented and only
mozilla.org seems to use". Since it views CVS, this sort of
calculation is easy for it.
It was pointed out by Axel Hecht that due to the requirements of
l10n work, Mozilla actually uses this feature "at least once per
week".
* Branching subdirectories in SVN is not intuitive...
* ...which means this is probably a good time to bring up 'mkdir -p'
(automatically create parent directories; see issue #1776), as well
as 'rm -k/--keep' (only "unversion" files, do not delete the working
files), and 'diff -s/--summary' (status-like diff output; see issue
#2015), all of which were desired by clkao.
[Question: Did someone start on a patch for 'svn diff --summary'
recently? I think I may have seen that on the dev@ list... Yes.
In http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=108496,
Peter Lundblad says: "The API part of this is already implemented
some time ago. So, it is quite low-hanging to do the cmdline GUI
part." -kfogel]
* Smart patch format. A patch format that can represent every kind of
transformation that could be transmitted by 'svn update'. We should
make sure to be compatible with SVK when we do this; clkao and
kfogel have already discussed this, and there's been some talk on
dev@subversion.tigris.org too.
Comments from projects that switched from CVS to SVN:
-----------------------------------------------------
* The w.c. space penalty is a real issue for large projects. Disk
space is not as cheap as we thought, those .svn/text-base/* files
hurt. See http://subversion.tigris.org/issues/show_bug.cgi?id=525.
[gerv: Random thought - if you can't easily do copy-on-write, could
you perhaps share text-base files by hard-linking between multiple
checkouts of the same tree (which is where this problem normally
hits hardest.) Yes, OK, there are scary thoughts there about trees
no longer being independent of each other...]
* Hosting the repository and migrating the user base were issues for
at least one open source project (Docutils, reported by Felix
Wiemann):
- There weren't many free Subversion hosting services that offer
enough features; see
<http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/felixwiemann/subversion.txt?rev=3080>
for a list of requirements we had. We chose BerliOS, which is
scary though because they provide little support.
Tigris (recently?) started to offer free Subversion hosting as
well, but it's a bit difficult to find that out from their web
site, and it isn't listed in the Subversion Project Links.
- Repository migration went flawless with cvs2svn (except for some
binary files being garbled).
Since there seemed to be some interest in that: We even could've
migrated the repository in several passes (migrating one part at a
time) by converting a part and then dumping the resulting
repository. Note however that commit dates would get out-of-order
(non-chronological) so that -r{DATE} doesn't work anymore.
- Regarding migrating the user base: There's some natural tension to
switch the SCM because developers have to install a new tool.
That seemed acceptably easy in this case, however. Also, all
developers have to manually re-register at the new site (BerliOS)
to get access to the repository. But overall that part of the
migration went quite painless.
* One group rejected BitKeeper for UI reasons.
* One person commented that distributed systems don't address
migration concerns. Also, they don't clearly say how to implement a
centralized-style system on top of the decentralized substrate. In
general, they need more process guidance. Subversion probably gets
off easy here because it takes advantage of a process people already
know, because they used CVS before.
* Also, the distributed systems don't have GUI tools, at least not as
many so far. I (kfogel) took this comment as indicating that the
overall "tool ecosystem" is an important part of the decision for a
lot of groups.
* GIT and BK have GUIs that display topology. I think ClearCase does
too, btw. Wish we'd had time to go into more detail about exactly
how these viewers are used, and how often. Anyone care to comment?
[jackr: Yes, ClearCase has a graphical topology viewer. Mixed
success. Tends to become absolutely crucial to managing
branches at a certain level of complexity; tends to destroy
the server with its server-side computations at about "that
level plus epsilon". Example: parallel development of some
new feature, occasional ladder-merges from trunk out to that
branch keep it in sync. Just before delivering the work to
the world on trunk, you wonder "what's happened since my last
merge-out?"
Another example: we branch releases off trunk just before
release, for final stabilization. Then we create patches on
that same branch. Sometimes, we fork a new branch for a
maintenance release, sometimes we just extend the existing
branch. Now, you're assigned to provide an urgent patch to
some old maintenance release: quick: do you use the parent
release branch, or is there a maintenance branch? In SVN,
you may be able to handle this with a listing of branches/
and some knowledge of branch-naming strategies, but in
ClearCase there's nothing quite analogous.]
Attendees:
----------
* Gervase Markham <gerv {_at_} mozilla.org>
Large CVS repository (mozilla), small SVN (personal)
* Chia-Liang Gao <clkao {_at_} clkao.org>
SVK, SVN, p4, CVS
* Ottone Grasso <ottone.grasso {_at_} tilab.com>
SVN
* Mauro Borghi <mauro.borghi {_at_} telecomitalia.it>
Small CVS and SVN
* Axel Hecht <axel {_at_} mozilla.com>
1 SVN + N CVS
* Felix Wiemann <felix.wiemann {_at_} ososo.de>
SVN, CVS, MKS
* Greg Stein <gstein {_at_} google.com>
CVS, SVN, p4
* John Viega <viega {_at_} securesoftware.com>
Didn't say.
* Brian Fitzpatrick <fitz {_at_} google.com>
CVS, SVN, p4
* Sander Striker <striker {_at_} apache.org>
SVN, CVS
* Stefan Taxhet <stefan.taxhet {_at_} sun.com>
CVS (OpenOffice.org)
* Christian Neeb <chneeb {_at_} gmx.net>
CVS, PVCS
* Arjen Schwarz <arjen.schwarz {_at_} gmail.com>
No version control.
* Erik Hülsmann <ehuels {_at_} gmail.com>
SVN, CVS
* Dobrica Pavlinusic <dpavlin {_at_} rot13.org>
Legacy CVS, SVN, SVK, svn2cvs.pl
* Gonçalo Afonso <gafonso {_at_} gmail.com>
CVS
* David Ramalho <dramalho {_at_} blackorange.pt>
CVS, SVN, SVK
* Karl Fogel <kfogel {_at_} collab.net>
SVN, CVS
Also, Jack Repenning <jrepenning {_at_} collab.net> did not attend,
but read the notes and added some comments; search for "jackr".
## Local Variables:
## coding:utf-8
## End:
## vim:encoding=utf8