OOoSCM Minutes 2007-11-09 IRC log

-->| blauwal (n=jr93709@sd-socks-197.staroffice.de) has joined #oooscm <blauwal> Hi <kendy> blauwal: I guess you will be the moderator? <blauwal> OK <_Nesshof_> doko: ping <doko> pong <blauwal> First, I think we should make this a weekly regular IRC meeting. Any suggestions for weekday and time? <_Nesshof_> and poolie ? =-= Mode #oooscm +o blauwal by _Nesshof_ <kendy> blauwal: Fri 14 UTC is fine here <blauwal> for me, too <jam-laptop_> poolie: will try to be around, but he has to give a presentation this morning <blauwal> ok -->| mod (n=mod@dslb-084-063-122-035.pools.arcor-ip.net) has joined #oooscm <jam-laptop_> I believe that poolie/lifeless/ianc and some others from our team wouldn't be able to make it normally at 14:00 UTC, (they are in AU) but I can make it -->| markit (n=marco@88-149-177-66.static.ngi.it) has joined #oooscm <doko> fine for me <blauwal> Well the topic of these meetings is to come to a common understanding about the pro/cons of the diverse SCM systems with respect to OOo and hopefully to provide a proposal to the steering committee <blauwal> We'll need to provide some comparable numbers about performance characteristics -->| erAck (n=er@sd-fw-out.staroffice.de) has joined #oooscm |<-- doko has left freenode ("Bye") -->| doko (n=doko@pool-71-124-234-44.bstnma.east.verizon.net) has joined #oooscm <doko> reconnected. <blauwal> We'll need to a priorized list which SCM meets which part of our requirements well, and which less <blauwal> jam-laptop_: Any other suggestions for weekday/time? <jam-laptop_> blauwal: I'm guessing that 1400 may be the best time. It is going to be near impossible to coordinate a Europe + AU + US time. <--| markit has left #oooscm ("Konversation terminated!") <blauwal> jam-laptop_: yes, that will be difficult. So 14 UTC on Friday is agreed =-= jam-laptop_ is now known as jam <jam> sounds good <blauwal> So how to proceed? We need comparable migrated repositories to provide meaningful numbers <kendy> blauwal: Maybe we also could introduce a bit first? ;-) <kendy> blauwal: I think I don't know jam and others here, so... * kendy will start ;-) <blauwal> kendy: right :) <kendy> I'm Jan Holesovsky, work for Novell, and I'm in favor of git ;-) <kendy> I've already created a full import to git with the entire history from 2000 <kendy> I'm not sure about the requirements for the tree, so maybe it does not look exactly how it should... <kendy> ... but otoh I have some ideas etc. as well, so if the requirements are not in stone yet, I'd have some proposals. <blauwal> I'm Jens-Heiner Rechtien, technical lead release engineering with Sun, Hamburg. I slightly favor Subversion and I've got a full SVN import :) <kendy> Next please :-) <jam> I'm John Arbash Meinel, and I work on the Bazaar team <jam> I'm coming a bit late to the discussion, so while I have a conversion, it doesn't really look much at all like the final request <blauwal> next please <_Nesshof_> I'm Martin Hollmichel, member of the ESC and project owner of the tools project * mod is only listening as I am interested in the discussion and not wanting to do my other work <_Nesshof_> so I would like to see a transistion from CVS to somewhat else happen <doko> Matthias Klose, OOo maintainance for Ubuntu during the last 2 1/2 years (which is now done by Chris Cheney) <poolie> i'm Martin Pool, I also work on Bazaar <poolie> (only partly at this meeting...) <doko> that's a bit of understatement ;) <blauwal> erAck: Eike, one sentence from you? <erAck> I'm Eike Rathke, a Sun developer just lurking, without any repository conversion. Currently preferring SVN from what I've heard and, this is the big plus for me as a developer, there are nice scripts to handle CVS and SVN from within the Vim editor, but for GIT there's just a some "display diff" script. <kendy> erAck: You are the last one it seems :-) * erAck prepared that in the meantime ;-) <kendy> blauwal: So - you had a wiki page with the requirements, right? <kendy> blauwal: Is that still valid? <blauwal> kendy: yes. <jam> http://wiki.services.openoffice.org/wiki/ <jam> with some important bits on: http://wiki.services.openoffice.org/wiki/SCM_Migration <blauwal> kendy: It's also hopefully as SCM agnostic ypuld make it <jam> (just because I still have those windows open) * mod wants to add, I am still forced to use Windows, so it is important for me that very good windows tools support are available as well <blauwal> jam: there is another page which lists the requiremnets <blauwal> one moment, I look it up <jam> oh, sorry, the first one was a bad link <jam> http://wiki.services.openoffice.org/wiki/SCM_Requirements <jam> I had started typing in the address bar. ^^ should be correct <kendy> jam: I've done http://wiki.services.openoffice.org/wiki/Git with some numbers & notes <jam> kendy: right, and doko has put up http://wiki.services.openoffice.org/wiki/Bzr <jam> Those might belong better in a subdir of SCM_Requirements... but they exist <blauwal> The problem is that we need comparable numbers <blauwal> I've got a proposal how to achieve that, but kendy has some proposals, too, so maybe kendy can you start <blauwal> ? <kendy> blauwal: OK <kendy> blauwal: I'd propose to go from the SCM_Requirements page, and turn it into more concrete one <kendy> blauwal: Like 'we want the history, and it should look like XYZ' <kendy> blauwal: I mean - if to track each commit, just integrations, or patch sets. <kendy> blauwal: And also if we allow a split of the entire archive to more logical subsets etc. <blauwal> kendy: that fits well with my proposal <kendy> blauwal: Great! <blauwal> On the SCM_migration page I got a recipe on how to do a subversion repository <blauwal> it contains, the number of code modules to be converted <blauwal> the branches and tags to be left out <blauwal> does some cleaning of the repository beforehaND <blauwal> I can see two possible ways to proceed. Either we do an import for each candidate which follows a similar path <kendy> blauwal: Of course, as always - some of the approaches help SVN, some help Git, I'm sure some will help Bzr - so we should try to focus on what the devs really need ;-) <blauwal> or we use a converted SVN repository and import from there into the other ones which should yield very comparable results <blauwal> kendy: Well, what the do developers really need :) <blauwal> kendy: I guess they want the SCM which doesn't get into their way. <kendy> blauwal: The devs need fast checkout, fast diff, fast merge ;-) <blauwal> kendy: They to need fast access to files from windows via NFS etc <kendy> blauwal: But you are right, we might discuss that endlessly - so... <blauwal> yes, this will not be the approach which will lead to a result <kendy> blauwal: I'd go the first path (we agree a common similar path), and each can also do a 'how I think the ideal import should look like' <kendy> blauwal: That would 1) give us some comparable numbers, and <kendy> blauwal: 2) maybe a better insight at strengths of the particular tool <blauwal> Yeah. But 2) should come after 1) First we need to work out strength and weeknesses <kendy> blauwal: Yes, agreed <blauwal> I understand that most tools can easily import SVN changesets <kendy> blauwal: [That's why I wrote 'each can also' - not has to ;-)] <kendy> blauwal: Not sure, never did SVN -> git import yet. -->| jam-laptop (n=jameinel@pool-71-124-234-44.bstnma.east.verizon.net) has joined #oooscm <jam-laptop> it seems the wireless here is a bit choppy <kendy> blauwal: And also not sure how the CVS -> SVN imports looks like (like what does it use, cvsps?) <blauwal> So would it be possible to do a 1:1 migration from SVN? Or something which is as closed as described in the scm_migration recipe? <jam-laptop> can someone PM me the discussion since 14:22? |<-- jam has left freenode (Read error: 104 (Connection reset by peer)) <blauwal> jam-laptop: we still discuss what to do first <blauwal> kendy proposed two steps =-= jam-laptop is now known as jam |<-- kendy has left freenode (Excess Flood) <blauwal> 1) do a comparable import (maybe inspired by the recipe mentioned) -->| kendy (i=kendy@nat/suse/x-59dcb3ea6eb01e9c) has joined #oooscm <kendy> jam: Done <blauwal> 2) do a ideal import to emphasize the strength of the SCM <kendy> jam: Got my /msg? <jam> kendy: yes, thank yoqu <jam> you <kendy> OK <kendy> blauwal: There is a git-svn-import, but I'm not sure how good it is. <kendy> blauwal: Of course - I'd need the SVN tree locally, I don't want to spend ages on the import ;-) <blauwal> kendy: I tried it, but it failed with a "two many parents" issue <blauwal> kendy: for this we'll have svnserve <blauwal> The repository will go up RSN <blauwal> actually it's up now <kendy> blauwal: wrt. 'too many parents' - then I'd really prefer that we define what and where, instead of svn -> git <blauwal> I'll send the details later <kendy> blauwal: [I'm not afraid of hacking the import scripts, but not my favorite job ;-)] <kendy> blauwal: OK <blauwal> kendy: OK than follow the recipe as best as possible <blauwal> kendy: We can adapt the recipe if necessary <kendy> blauwal: OK <blauwal> kendy: of course <kendy> blauwal: Where exactly is the receipe, please? [URL] <blauwal> I've read several articles about that SVN->XXX is easier than CVS->XXX <blauwal> the recipe is http://wiki.services.openoffice.org/wiki/SCM_Migration <kendy> blauwal: I mean, is that http://tools.openoffice.org/scm_migration/repositorystructure.ods ? <blauwal> that's part of it <blauwal> there is also a list of branches which can be ignored <blauwal> and a script to partition the cvs-up repository -->| doko_ (n=doko@75.144.175.202) has joined #oooscm <blauwal> actually the repository structure of all modern SCM and DSCM is based on changesets <blauwal> the recipe is of course not final, probably needs more tweaking <kendy> blauwal: OK <kendy> blauwal: I've looked into the scripts quickly now.... <kendy> blauwal: I'm quite opposed to the idea of having translations in the same repository as the code ;-) <blauwal> kendy: And I'm quite opposed to have them in a separate repository <blauwal> :) <kendy> blauwal: :-) <kendy> blauwal: Why? <kendy> blauwal: Never happens that you have to merge code & translations at the same time... <blauwal> kendy: The point it doesn't matter for a CSCM, it does for a DSCM, I know. We should keep that in mind <blauwal> kendy: Happens all the time <kendy> blauwal: Like the developer provides translations? <blauwal> Part of it#s are done via a database, but finally they need to be merged in a CWS <blauwal> often code module changes as well <blauwal> kendy: But we can discuss this later <kendy> blauwal: But it never happens in the same cws as the code, rightL <kendy> s/L/?/ <kendy> ;-) <kendy> Anyway <blauwal> kendy: It does happen in the same CWS <kendy> blauwal: As we agreed, let's do something comparable, and then the ideal repositories. <blauwal> So a plan could be: <jam> kendy: what are you using to get change sets out of CVS? <blauwal> 1) create comparable repositories <kendy> jam: Patched cvsps <jam> I've used some cvsps, but you need to do quite a bit of post processing to get the merges back, etc. <jam> kendy: care to share? <kendy> jam: Sure <blauwal> 2) host the on o3-build.services.openoffice.org <kendy> jam: Merges some 'integration' commits that are generated in the OOo CVS <blauwal> 3) each of us does some measuring of our work flow <blauwal> 4) compare numbers <blauwal> 5) see if there is a picture emerging <jam> (not to mention they have tags that don't really go across the whole repository... which means you sort of have to guess where they apply to files they don't touch) |<-- doko has left freenode (Read error: 110 (Connection timed out)) <blauwal> jam: I would like that script, too <blauwal> sorry I meant kendy <kendy> I'll post to dev@tool <jam> Which is where SVN => XXX would be easier, but the original CVS => SVN would still be guessing anyway. <jam> can you forward that to john@arbash-meinel.com ? <blauwal> Yeah, but cvs2svn seems to be quite sopisticated <blauwal> And we would have the same guessing for all SCMs <jam> blauwal: sure, but everything from CVS is a bit GIGO <kendy> blauwal: To understand your process better, you use cvsps as well, or does the cvs2svn has something else? <blauwal> yeah <jam> at least I haven't seen you deleting ,v files <blauwal> cvs2svn does something else <jam> or copying them because you wanted to simulate a rename <kendy> blauwal: OK, I'll check. <blauwal> jam: no I don't do that. I kill a few broken files, I drop a number of no longer needed branches and tags <kendy> blauwal: And - your SVN import is already up & available? <jam> blauwal: I mean the OOo team doesn't do that to their CVS repo, which is fairly common in cvs-land <blauwal> Please try it out: svn+ssh:svn@o3-build.services.openoffice.org <blauwal> Please try it out: svn+ssh:svn@o3-build.services.openoffice.org/svn <blauwal> jam: simulated renames by copying. No, thank god we refrained from taht <jam> blauwal: so I can get in to the svn server itself, is it possible to get a svndump or something comparable so we can set it up locally? <erAck> kendy: I don't know much about git. The wiki's git page says about Resync: "it's usually not necessary to do resynces with git;" how to assure then that the current development branch's change set is still appliable to the current master? (short answer please ;-) <blauwal> jam: svnsync can pull the repository <blauwal> erAck: git knows to do rebases <mod> there is a pretty long discussion about git for windows and it doesn't sound too good: <erAck> blauwal: without manual intervention? <mod> http://kerneltrap.org/mailarchive/git/2007/7/25/252773 <jam> you *can* rebase, but it is usually better to just merge, IMO <blauwal> erAck: As much manual intervention as with CVS and SVN. Conflicts <mod> if this is still the case, this would be really bad for windows developers when swiitching to git <blauwal> erAck: Of course only CVS in the CWS environment can do this <blauwal> mod: That's why we want to measure a number of things. <mod> having only a cygwin port is also not the best solution for people who would not need cygwin otherwise <mod> blauwal: sure <blauwal> mod: collect the numbers <jam> mod: there is a mingw port going on, but I did run across this: http://www.gelato.unsw.edu.au/archives/git/0701/38380.html <blauwal> mod: and later decide on the whole picture <mod> blauwal: just wanted to point to that thread, which is also commented by git develoeprs themselves <blauwal> mod: thanks <blauwal> mod: We'll have a look at it <erAck> blauwal: so in the end, if not wanting to burden that during integration to the RE, a resync aka rebase is necessary like with any other SCM. That entry on the wiki page then is a bit misleading. <blauwal> erAck: should be clarified, yes <jam> erAck: I think kendy was saying that you resync using merge, not rebase <jam> is that accurate kendy ? <kendy> jam: Yes <kendy> erAck: The wording is probably not the best. <erAck> kendy: seems like ;-) <blauwal> erAck: I works by pulling the latest changesets into your working copy. Conflicts need to be resolved, of course <kendy> blauwal: Yes <blauwal> erAck: conceptionally it's more or less the same as cwsresync <kendy> erAck: But I wanted to answer exactly your question, and <kendy> erAck: wanted to tell you the exact command, but the best I have at the moment is git-pull that takes you the changes but does not commit. <kendy> erAck: But that's not exactly what I originally meant with the sentence - * erAck feels relief that there isn't any magic involved ;) <kendy> erAck: I meant that you do not need a special magic just to make a resync <kendy> erAck: Just that you pull from master. <kendy> erAck: Is that an answer for you? ;-) <erAck> kendy: so, business as usual. Yes, that's a fine answer, thanks :) <kendy> erAck: Few lines above, s/git-pull/git-pull --squash/ <kendy> blauwal: svn checkout 'svn+ssh:svn@o3-build.services.openoffice.org/svn/trunk' gives me: <blauwal> So back on how to proceed. Do we agree that we should try to do import along the lines spelled out in SCM_migration? If this recipes need to be modified, we'll do that. <kendy> blauwal: svn: Client error in parsing arguments <kendy> blauwal: Is that expected? <blauwal> kendy: The upload finished about 3 min ago. <kendy> OK <blauwal> kendy: need to try it out ... send an email with the details <kendy> blauwal: OK <blauwal> kendy: You'll need a svn-1,4 client <kendy> blauwal: So - tasks until the next IRC session, <kendy> blauwal: Because I must go in <10 minutes, sorry * erAck will have some small Friday afternoon beer event now. <blauwal> No problem <erAck> cu guys. <blauwal> bye =-= erAck is now known as erAck_afk <kendy> blauwal: 1) read SCM_migration <blauwal> yes <kendy> blauwal: 2) comment on that from git/bzr perspective <blauwal> yes <kendy> blauwal: 3) try to achieve the same <blauwal> and the give me the result so I can host it here <kendy> blauwal: [might take some time, so at least have some progress there] <blauwal> kendy: sure. My import took 4 days :) <kendy> blauwal: As I said, I import in 1, so... ;-) The harder part is to get it to the same state you have. <blauwal> We might need to agree on a certain date to do test freeze of the CVS repsitory <kendy> blauwal: 4) have a look at the current svn import & see if it's viable to import to git directly from there. <kendy> blauwal: Right <kendy> blauwal: I'd say the date you did the import? <blauwal> blauwal: Yes. One moment I look <kendy> jam: Are the 1)-4) OK for you? <jam> sounds right to me <blauwal> I mail the details of the freeze * kendy takes the shoes on ;-) <blauwal> Or better, write it down on the wiki page <blauwal> see yo next Friday! <jam> blauwal: you aren't planning on freezing your production branch, right? Just the mirror that we are using for test conversions? <blauwal> yes <kendy> jam, blauwal: Thank you for joining, looking forward to seeing you the next week :-) <doko_> have a nice weekend <blauwal> cu <kendy> blauwal: Will you please post the backlog to dev@tools? <blauwal> kendy: I'll do <kendy> blauwal: Thanks! <kendy> Bye! <jam> bye kendy <blauwal> Ok, let's close for today, see you all next week <jam> have a good weekend <blauwal> bye!