| 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 https://issues.apache.org/jira/browse/SVN-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 |