OOoSCM Minutes 2007-11-09 IRC log

From Apache OpenOffice Wiki
Revision as of 16:22, 12 November 2007 by Hr (Talk | contribs)

Jump to: navigation, search
	-->|	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!
Personal tools