Difference between revisions of "OOoSCM Minutes 2007-11-23 IRC log"
From Apache OpenOffice Wiki
|Line 197:||Line 197:|
**** ENDING LOGGING AT Fri Nov 23 16:30:30 2007
**** ENDING LOGGING AT Fri Nov 23 16:30:30 2007
Latest revision as of 01:32, 15 December 2009
**** BEGIN LOGGING AT Fri Nov 23 14:55:57 2007 Nov 23 15:03:08 <blauwal> Hi Matthias Nov 23 15:04:26 --> _Nesshof_ (email@example.com) has joined #oooscm Nov 23 15:04:39 --> erAck (firstname.lastname@example.org) has joined #oooscm Nov 23 15:05:09 <blauwal> Hi Nov 23 15:05:31 <erAck> hi, a bit late but it seems I didn't miss much? Nov 23 15:05:41 <blauwal> nothing, yet Nov 23 15:06:17 <blauwal> Hopefully Jan and John will join us today Nov 23 15:06:31 * erAck goes on hacking.. Nov 23 15:11:09 <blauwal> Ok, seems like this will be a small session today. Nov 23 15:11:26 <blauwal> doko: I've got a number of question regarding bazaar Nov 23 15:12:16 <doko> blauwal: ok, I'll try to answer. John is not here, thanksgiving weekend in the US Nov 23 15:12:40 <blauwal> doko: I see Nov 23 15:13:14 <blauwal> doko: Do you know how successful John was with his import effort? Nov 23 15:14:01 <doko> no, unfortunately not. I forwarded the modified script to him Nov 23 15:14:53 <blauwal> I played around a bit with svn2bzr (the version which takes a svn dump) but it's very slow, and I don't sse why Nov 23 15:15:21 <blauwal> Is using svn2bzr a stupid idea Nov 23 15:15:22 <blauwal> ? Nov 23 15:16:15 <doko> which version do you use? Nov 23 15:16:35 <blauwal> it needed several days to just read 17000 of 500000 revisions. I use the latest one. Nov 23 15:16:45 <doko> iirc correctly john did use something else Nov 23 15:17:07 <blauwal> Do you know what? Nov 23 15:17:49 <doko> I only used that for one small project in the past Nov 23 15:18:40 <blauwal> I'm asking because I absolutely like the feature set of bazaar (it could solve all our problems) but I need a representive repository to judge the scalability Nov 23 15:19:25 <blauwal> OK another question: Nov 23 15:20:16 <blauwal> Do I understand it right that with bazaar you could have a setup with central shared repository and only local branch history? Nov 23 15:20:24 <doko> I know :-/, asking somebody else from the bzr team Nov 23 15:21:02 <blauwal> but full history if you want? Nov 23 15:21:53 <doko> full history should not be a problem, but I don't know how to avoid the complete history for a checkout. Nov 23 15:22:02 <blauwal> If that#s the case we could use full local history for the nomadic developers and some kind of shared remote repository setup for the small team guys Nov 23 15:22:34 <blauwal> doko: I read something like checkout --lightweight Nov 23 15:24:35 * erAck as a developer working in that small team environment on CWSs notes that something like that is a must-have. Nov 23 15:24:44 <doko> yep, reading on http://bazaar-vcs.org/SharedRepositoryTutorial Nov 23 15:25:03 <doko> search for "Checkouts" Nov 23 15:25:36 --> kendy_ (i=kendy@nat/suse/x-c7b7c9f939868862) has joined #oooscm Nov 23 15:25:47 <blauwal> Hi Jan Nov 23 15:25:49 <kendy_> Hi, seems I forgot the meeting :-( Nov 23 15:25:58 <kendy_> Sorry for that! Nov 23 15:26:13 <blauwal> You haven't missed that much. Nov 23 15:26:28 <blauwal> I was just asking about the import efforts Nov 23 15:26:54 <kendy_> I wanted to try the svn -> git, but unfortunately the mirror is still in progress. Nov 23 15:27:01 <kendy_> Even with svn+ssh Nov 23 15:27:04 <blauwal> and we were talking a bit about the shared repostory feature of bazaar Nov 23 15:27:45 <blauwal> kendy_: Oh. Yes it will take a time. I've a dump of that repository here (about 20G), would help that? Nov 23 15:27:56 <blauwal> 20G compressed that is Nov 23 15:28:47 <kendy_> blauwal: Well, I don't know much about managing svn - so if I can just grab it & unpack, and that would be a working mirror, perfect for me :-) Nov 23 15:29:14 <doko> could you make this one rsyncable? Nov 23 15:29:27 <blauwal> kendy_: Should be. On the other hand, after the weekend you should have the whole mirror anyway. Nov 23 15:29:51 <blauwal> doko: Don't know, need to ask IT what I'm supposed to offer on that machine Nov 23 15:30:10 <kendy_> Hopefully - if it does not break as the last time ;-) [we had a network outage for a while, and it broke it..] Nov 23 15:30:29 <blauwal> kendy_: or is it still slow with svn+ssh? Nov 23 15:30:44 <kendy_> blauwal: With rsync over ssh, it should be OK without any IT interation Nov 23 15:31:16 <blauwal> kendy_: you can do it incrementally. Nov 23 15:31:26 <kendy_> blauwal: svnsynchronize seems to be as slow with svn+ssh as with http Nov 23 15:31:45 <blauwal> kendy_: Hmm. I tried it from my homeline and it was quite fast Nov 23 15:31:56 <kendy_> blauwal: Yes - but then I got out of of the disk space, and that one was unrecoverable ;-) Nov 23 15:32:06 <kendy_> [some stalled lock somewhere ;-)] Nov 23 15:32:20 <blauwal> kendy_: :) It's dammed huge, right Nov 23 15:32:28 * kendy_ installed a second disk to the machine, should be safe now Nov 23 15:33:25 <blauwal> kendy_: If you didn't got it by Monday, send me an email and I setup rsync Nov 23 15:33:38 <kendy_> blauwal: Great, thanks! Nov 23 15:34:50 <kendy_> Otherwise - no other progress from my side unfortunately. Nov 23 15:35:17 <blauwal> kendy_: one question, does git allows a setup with a central repository and only partial local history? Nov 23 15:35:40 <kendy_> blauwal: Yes, shallow clone. Nov 23 15:35:51 <kendy_> blauwal: In fact, it is the setup we would like to see. Nov 23 15:36:06 <kendy_> blauwal: Unfortunately I'm not that familiar with shallow clone yet Nov 23 15:36:20 <blauwal> kendy_: is that transparent? I mean if someone wants the full history, is there a way to do it from that worksapce? Nov 23 15:36:33 <kendy_> blauwal: Basically it's simple - you just specify --depth=<depth of the history> during clone, Nov 23 15:36:54 <erAck> kendy_: what's the depth there? Nov 23 15:36:58 <kendy_> blauwal: but I still get too big checkout; I must be doing something wrong. Nov 23 15:37:11 <kendy_> erAck: Number of checkout you are interested in. Nov 23 15:37:17 <kendy_> checkouts Nov 23 15:37:34 <blauwal> checkouts? or changesets? Nov 23 15:37:39 <kendy_> sorry Nov 23 15:37:43 <kendy_> commits of course Nov 23 15:37:49 <kendy_> == changesets Nov 23 15:38:31 * kendy_ should sleep more to be able to talk even on Friday afternoon ;-) Nov 23 15:39:58 <blauwal> kendy_: Given the following scenario: I do a flat checkout (depth=1, or low number) and work on that (my branch). Now unexpectantly I need to know the history of a file, which isn't there locally, of course. Could git than access the history over the network? Nov 23 15:40:02 <kendy_> blauwal: Yes, according to the doc, you can deepen the history using --depth=<depth> in git-pull Nov 23 15:40:17 <kendy_> blauwal: Unfortunately did not try it myself yet. Nov 23 15:40:47 <blauwal> kendy_: OK Nov 23 15:40:54 <kendy_> blauwal: I have to test the shallow clone more extensively, that's basically the way to go ;-) Nov 23 15:41:17 <kendy_> blauwal: That way we can scale even in 5 years from now. Nov 23 15:41:45 <erAck> kendy_: and that pulls the depth of the entire repository cloned, or just on a per module basis? Nov 23 15:42:27 <kendy_> erAck: Not sure what do you mean by 'per module'? Nov 23 15:43:16 <erAck> kendy_: e.g. if I'm working on module 'sc' I'm mostly not interested in being able to checkout changesets of other modules like 'sw'. Nov 23 15:44:26 <erAck> kendy_: however, I like to peek into history like with cvs log and cvs annotate for other modules as well. Nov 23 15:45:10 <blauwal> kendy_: I've read a lot about bazaar lately, and the bazaar shared repository approach could be the answer to my concerns about a DSCM. It looks like we could have it both the advantages of DSCM (local history if you want, nice merge capabilities) and CSCM (immediate publishing for those who want it, less local diskspace etc) Nov 23 15:46:10 <kendy_> erAck: It depends how we do the git repository. With the import of blauwal's tree, you'll have all the changes. Nov 23 15:46:40 <erAck> kendy_: the question is, do I have to clone them locally? Nov 23 15:46:45 <kendy_> erAck: But see my other efforts on dev@tools - to split the OOo sources into more pieces. But that is orthogonal to the new scm Nov 23 15:46:48 <blauwal> kendy_: well 220 repositories for all our modules will not be an option :) Nov 23 15:47:19 <kendy_> blauwal: No, I propose about 20 repositories. Nov 23 15:47:29 <kendy_> Anyway Nov 23 15:47:43 <blauwal> kendy_: still, by far too many Nov 23 15:48:18 <doko> can these repositories be combined/aggregated using a meta repository? Nov 23 15:48:24 <kendy_> blauwal: Not at all ;-) For normal Calc development you would need about 4 Nov 23 15:48:45 <kendy_> blauwal: Anyway - let's let it aside for now ;-) Nov 23 15:48:49 <blauwal> kendy_: yes, but 3 of the 4 would also be needed by sw, sd etc Nov 23 15:48:51 <erAck> kendy_: what is "normal" Calc development? ;-) Nov 23 15:49:30 <kendy_> erAck: ehm :-)) Nov 23 15:50:15 <kendy_> erAck: For me it's 'fix a bug that eg. something in a cell is misplaced', etc. Nov 23 15:50:38 <blauwal> So svx would be claimed by the writer team, by the calc team and the grahics team. Two loose, mean they would have to work "foreign" repository, this no history preserving moves, etc Nov 23 15:50:47 <kendy_> blauwal: Yes, 4 would be needed also for sw, but 3 of them are the same as for sc ;-) Nov 23 15:51:11 <kendy_> blauwal: Exactly - that's why I propose svx in a package shared by all. Nov 23 15:51:18 <erAck> kendy_: say, I want to work on Calc, i18npool, unotools, svtools and tools (my usual set), how many GBs do I need to pull to my local disc? Nov 23 15:51:30 <blauwal> kendy_: So the usual CWS would use more than one repostory Nov 23 15:52:22 <blauwal> kendy_: thus you need to sync the meta information (tags, branches) between the repositories ... not a nice porspect Nov 23 15:54:48 <blauwal> well, if we can make use of shallow clones or shared repository the need for multiple repositories go away I would be all for it. Nov 23 15:55:47 <kendy_> blauwal: You really got me into a debate I did not want to get today ;-) Nov 23 15:55:55 <blauwal> :-) Nov 23 15:55:55 <kendy_> blauwal: So - Nov 23 15:56:19 <kendy_> blauwal: The thing is - for the outside developers, OOo is just too huge to get into Nov 23 15:56:50 <kendy_> blauwal: We need to balance the burden of the RE's (case of binary incompatible change between repositories) Nov 23 15:57:02 <kendy_> blauwal: and the ease of use for newcomers. Nov 23 15:57:26 <kendy_> blauwal: The entire repository as is is just scary ;-) Nov 23 15:58:06 <blauwal> kendy_: Many repositories do not really ease the use for newcomers. Dependencies are still be there. Just having them in another repository does not remove the dependency. Nov 23 15:58:31 <kendy_> blauwal: But imagine that on normal linux distro Nov 23 15:58:32 <blauwal> kendy_: Additionally you need to know that that sal call is in the porting repository Nov 23 15:58:44 <kendy_> blauwal: You want to change something in Calc Nov 23 15:58:54 <blauwal> the cppu call is in the bridging rep etc Nov 23 15:59:22 <kendy_> blauwal: Just install the OpenOffice.org-devel packages the distro provides, Calc sources, and start happy hacking ;-) Nov 23 15:59:40 <blauwal> kendy_: want work, because you don' habe the headers Nov 23 15:59:51 <blauwal> dont have the headers Nov 23 16:00:09 <blauwal> the build environment etc Nov 23 16:00:10 <kendy_> blauwal: You have - you get them in the -devel package Nov 23 16:00:22 <kendy_> blauwal: Like in with any other normal library Nov 23 16:00:55 <blauwal> kendy_: you would need to install *all* just without sw and sd, that#s no improvement Nov 23 16:01:22 <blauwal> kendy_: Anyway, you could do it that way, but why slpit the repository? Nov 23 16:01:26 <kendy_> blauwal: That is an improvement, see the sizes I sent to dev@tools Nov 23 16:01:47 <blauwal> with svn just checkout sc ... that's it Nov 23 16:01:57 <blauwal> you just need to know the name Nov 23 16:02:41 <blauwal> kendy_: It will be hard to sell me the *need* for multiple repositories as *advantage* Nov 23 16:02:59 <blauwal> kendy_: I might accept them as necessary *evil* :) Nov 23 16:03:28 <kendy_> blauwal: :-) Nov 23 16:03:43 <erAck> kendy_: next step after I started hacking: I want to know when and why a particular line of code was introduced (because I'm working on a regression that was introduced with the latest release). How to? I realize that a change is related to other changes in the framwork module, how to find out details? Nov 23 16:03:51 <blauwal> kendy_: But it will be always a point against the SCM which requires them. Nov 23 16:05:02 <erAck> kendy_: and of course I have only 4GB free disk space available on my notebook. Nov 23 16:05:15 <kendy_> blauwal: Yes. Nov 23 16:06:02 <blauwal> erAck: More locally needed space will be necessary with ervery replacement for CVS Nov 23 16:06:12 <kendy_> erAck: So - as I said, I did not test the shallow clone well enough to tell you exact sizes ;-) Nov 23 16:06:39 <kendy_> erAck: But the import from spring I did had 2G with the entire history. Nov 23 16:06:45 <erAck> blauwal: the question is how much. GIT seems to stretch limits enormously. Nov 23 16:06:56 <kendy_> erAck: I expect the shallow clone without history should be about 500M Nov 23 16:07:13 <kendy_> [without history == --depth=1] Nov 23 16:07:26 <blauwal> erAck: that's why I finding the bazaar shared repository approach so intriguing Nov 23 16:07:33 <kendy_> erAck: But not sure how it increases in size when you deepen it, et.c Nov 23 16:07:52 <kendy_> blauwal: What is exactly the shared repostiory in bazaar? Nov 23 16:08:06 <kendy_> blauwal: You can of course share the repository in git as well Nov 23 16:08:15 <erAck> kendy_: will I be able to look at earlier changes (like cvs diff) with depth=1? Nov 23 16:08:52 <blauwal> kendy_: I'm not totally sure how it's works, but it looks like you can have a part of the history locally and transparent (without the need for a pull) the rest somewhere remote Nov 23 16:08:54 <kendy_> blauwal: You can also use a repository you already have locally as a base for clone to save network traffic. Nov 23 16:09:19 <blauwal> kendy_: sure, everyone will have a pristine copy somewhere Nov 23 16:09:26 <kendy_> blauwal: see git-clone --reference Nov 23 16:10:05 <kendy_> blauwal: and git-clone --shared Nov 23 16:10:19 <blauwal> It would be nice that if you decided to have a restricted history locally the SCM could look up the ommitted history over the network# Nov 23 16:10:31 <blauwal> even if it costs more time Nov 23 16:10:35 <kendy_> erAck: Don't know yet. Nov 23 16:14:30 <blauwal> OK, I think we will turn in circles, without knowing if *one* repository with "shallow" or shared characteristics could be a viable solution for us. Nov 23 16:15:54 <blauwal> As long as that is not completely proven as impossible we should still aim for a single code repository. Nov 23 16:16:15 <blauwal> Later we can think about splitting it Nov 23 16:16:57 <kendy_> blauwal: Agreed. Nov 23 16:17:11 <blauwal> kendy_: could you look up some details about git --shared? Nov 23 16:17:49 <blauwal> kendy_: I'll have a look myselves but the fit documentation is sometimes hard to read Nov 23 16:17:56 <blauwal> s/fit/git/ Nov 23 16:18:29 <blauwal> Especially it would be nice to know if the following is possible Nov 23 16:18:41 <blauwal> 1) some fill repository on the network Nov 23 16:19:00 <blauwal> 2) I branch locally without or with a little history Nov 23 16:19:29 <blauwal> 3) now I need to know the history of a few files, so I either access the information over the network, or Nov 23 16:19:44 <blauwal> pull the history from remote into my local repository Nov 23 16:20:51 <kendy_> http://www-cs-students.stanford.edu/~blynn/gitmagic/ch03.html 'Light-Speed Multitask' seems to tell more about usage of --shared Nov 23 16:21:14 <kendy_> [that's not an answer for 1-3] Nov 23 16:21:41 <kendy_> blauwal: Not sure if I understand 1)? Nov 23 16:22:14 <blauwal> kendy_: typo: 1) We have a full repository somewhere on the network Nov 23 16:22:47 <blauwal> for example the full upstream repository with the complete history Nov 23 16:23:56 <blauwal> I'll send a mail with the scenario I have in mind on dev@tools (and with less typos I hope :) ) Nov 23 16:24:32 <kendy_> blauwal: So - if I understand that correctly - you ask: after you have done a shallow clone, if it's possible to extend the history so that you can diff what you need, right? Nov 23 16:24:56 <blauwal> yes Nov 23 16:25:02 <kendy_> blauwal: As I said - from the doc it should be easily possible, but did not try it myself yet, unfortunately :-( Nov 23 16:25:23 <kendy_> blauwal: git-pull --depth Nov 23 16:25:58 <blauwal> will that pull the full history? I that case I have not much won by doing a shallow branch Nov 23 16:26:16 <blauwal> blauwal: or can I pull the changesets I'm interested in? Nov 23 16:27:00 <kendy_> blauwal: No, git-pull has the --depth to limit. So I guess, you should be able to do git-clone git://blah --depth=1 ; .... ; git-pull --depth=100 Nov 23 16:27:03 <blauwal> lets' say all changesets which affected file xyz? Nov 23 16:27:21 <kendy_> blauwal: But as I say - I did not try, so maybe I am wrong... Nov 23 16:27:40 <blauwal> kendy_: Is there a way to say - pull me all changessets which changed this file 'xyz'? Nov 23 16:28:10 <blauwal> kendy_: OK let's discuss this next week. I'll do a lot of reading until then :) Nov 23 16:28:26 * kendy_ too ;-) Nov 23 16:28:51 <blauwal> Shall we close this meeting today? Nov 23 16:29:29 <blauwal> I'll post the log on the wiki Nov 23 16:29:45 <kendy_> blauwal: Thanks! Nov 23 16:29:57 <doko> that would be nice Nov 23 16:30:07 <blauwal> Good ... see you next week! Nov 23 16:30:19 <kendy_> Have a nice weekend! :-) Nov 23 16:30:25 <blauwal> bye **** ENDING LOGGING AT Fri Nov 23 16:30:30 2007