Posted by jpetso on June 17, 2009 at 8:33am
Whoa, seems I skipped one set of logs again. Anyways, here's what we discussed last Sunday. This time with even nicer formatting.
Topics include:
- Conceptual issues for dhax's Git hooks (→ using the 'update' hook for permission control so that branch pushes don't depend on other branches' validity)
- The future of source items in the main API module (→ we want them as an optional bonus instead of a log-parse-time requirement)
- Proper merging of commits from Git into CVS (→ git cvsexportcommit allows an "-m" option for prefixing a string to the commit message)
- Current status and current issues in marvil07's OOP conversion (→ ArrayAccess implementation works pretty good as intermediary compatibility layer, several issues still to be worked out)
- Whether Version Control API will drop its CVS history in favor of easier Git collaboration (→ it won't)
- Some ponderings on rewriting history with git rebase. Note that dhax has prepared his versioncontrol_svn hook scripts patch for extra nice history, which is way cool. (Take that, webchick! ;) )
[20:04:18] Join You have joined the channel #drupal-vcs (n=jpetso@93.83.249.126). [20:04:18] Topic The channel topic is "http://github.com/sdboyer/drupal-git-scripts/tree/master". [20:04:18] Topic The topic was set by sirkitree on 5/13/09 6:40 PM. [20:04:18] Channel [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [20:04:41] <marvil07> hi corni [20:04:47] <jpetso> hi marvil07 [20:04:50] Mode Channel modes: secret, no messages from outside [20:04:50] Created This channel was created on 5/8/09 7:36 AM. [20:04:52] <corni> hi jpetsp [20:04:55] <jpetso> hi corni, too [20:04:55] <corni> *jpetso [20:05:49] <corni> you'll ping me when we start? [20:05:55] <jpetso> yep, sure [20:06:02] <jpetso> at :30 [20:06:22] <marvil07> hi jpetso [20:06:42] <jpetso> i need to review some versioncontrol_svn code in the meantime [20:11:45] <chrono325> jpetso: we're starting at :30? [20:15:21] <corni> everyone except sdboyer is here already? [20:21:15] Quit marvil07 has left this server ("out"). [20:21:58] Join marvil07 has joined this channel (n=marvil07@190.222.116.158). [20:39:02] <jpetso> boah, merging commits into Git repositories *and* Drupal CVS in a way that actually works is HARD [20:40:54] <corni> :D [20:42:28] <jpetso> ok, sdboyer is not here (yet?) but let's start anyways [20:42:51] <jpetso> marvil07, chrono325, skiquel: ping, and see above [20:43:00] <jpetso> and corni, of course. [20:43:15] <corni> thanks ;) [20:43:48] <jpetso> everybody here? [20:44:10] <chrono325> yup [20:44:30] <marvil07> jpetso: didn't try drupal-git-scripts way, but git-export commit is not such a painful :p [20:45:11] <jpetso> marvil07: i allow you to guess what git command drupal-git-cvsexportcommit is using ;-) [20:46:14] <marvil07> well, mayba some time consuming at the start :p [20:46:24] <marvil07> s/mayba/maybe [20:46:46] <jpetso> marvil07: my major gripe is that a) CVS export requires rebasing in order to stay true to the upstream repository, and b) it's not so simple to change commit messages further down the commit stack [20:47:25] <jpetso> marvil07: i just imported your latest commit on master, and i could just as well have copied the patch by myself [20:47:37] <jpetso> ok, so who wants to begin? [20:47:59] <chrono325> git hooks are harder than svn hooks :( [20:48:03] <corni> jpetso: I had a discussion with dww recently, and we somehow got to the source_items stuff, and why we have that in the core api instead of marking it as optional to implement [20:48:57] <corni> (or let chrono325 begin...) [20:49:01] <corni> he's then student :D [20:49:04] <corni> *the [20:49:09] <jpetso> k, chrono325 has the word! [20:49:27] <chrono325> jpetso, corni: why thank you :) [20:49:36] <jpetso> :D [20:50:26] <chrono325> so I've been working on the git hooks, but have gotten a bit stuck. The general problem is that each update can contain multiple commits, the logic for working with it is more complicated. [20:50:53] <chrono325> in svn, every commit triggered a single update, so checking for the path and username was more straightforward [20:50:57] <corni> so you don't just bootstrap drupal+call the log parser? [20:51:00] <corni> ah ok [20:51:03] <corni> sure... [20:51:10] <jpetso> yeah, i was kinda aware of that issue. [20:51:27] <jpetso> corni: the log parser doesn't do access checks. [20:51:30] <chrono325> it's not insurmountable, but I spent a while working on things before I remembered that [20:51:41] <chrono325> and realized that I was only checking the last commit, rather than all of them [20:52:08] <chrono325> the log parser would probably work for the post-update hook, but would likely be a bit slower [20:52:16] <jpetso> yeah [20:52:26] <chrono325> since the post-update hook gives you the names of all of the updated refs [20:52:38] <chrono325> as well as the old and new commit names [20:53:03] <corni> then feel free to use the vcs api to insert new commits [20:53:07] <jpetso> isn't it possible to just check all of the commits independently, and block all of them if one is invalid? [20:53:10] <corni> or abstract some stuff out of the log parser [20:53:22] <chrono325> so you would only have to check exactly the ones which changed, rather than having to figure out what is different between the repo and the database. [20:54:06] <chrono325> jpetso: yes, you can do that, but the logic for gathering the relevant data for each commit is a bit more complex than in SVN [20:54:38] <chrono325> there are two main options for a pre-commit-esque hook: update and pre-receive [20:54:54] <jpetso> so multiple commits is not the only issue, then [20:55:00] <chrono325> I chose 'update' for now, but it might make more sense to use 'pre-receive' [20:55:26] <chrono325> jpetso: correct, though there is a fairly minor difference between the two [20:55:53] <chrono325> 'update' is run once for each ref being updated and has its arguments passed on the command line [20:56:17] <chrono325> 'pre-receive' is run once for each push (which can update multiple refs), and receives its arguments on stdin [20:56:49] <jpetso> chrono325: one failed update aborts the push, no? [20:56:56] <chrono325> there will be more overhead when using 'update' if the user is pushing multiple branches, since drupal will have to bootstrap on each one [20:57:00] <chrono325> jpetso: correct. [20:57:27] <chrono325> jpetso: more specifically, in 'pre-receive', one failed ref aborts the whole push [20:58:20] <chrono325> so if I am pushing updates to branches 'master', 'testing', and 'next', and I am using a 'pre-receive' hook, then a failure in 'next' will result in 'master' and 'testing' not being updated [20:58:51] <chrono325> whereas with 'update', a failure in the hook for 'next' will still allow 'master' and 'testing' to complete successfully. [20:59:04] <jpetso> mmkay... [20:59:13] <chrono325> otherwise, the hooks are essentially the same (aside from the way input is read and the cost of starting a new process) [20:59:43] <chrono325> I think that in most cases, people will only be updating a single ref per push, but it is worth thinking about [21:01:14] <jpetso> i wouldn't bet on a single ref per push being the common case, but i think 'update' is fine if it improves the developer experience [21:02:24] <jpetso> if we want, we could always upgrade to a system that checks the refs in pre-receive, stores the results in a temp file, and returns them in update [21:02:45] <chrono325> true [21:02:58] <jpetso> (similar to the way the CVS backend combines data from different directories, which CVS itself does not do) [21:02:59] <chrono325> or even have a hook for both and let the site admin decide [21:03:17] <chrono325> it shouldn't be that much more work, since the scripts will be almost identical. [21:03:45] <jpetso> you think anyone wants to break their head about that kind of issues? [21:04:24] <jpetso> i'd say if someone requests that kind of flexibility, we can think about it, otherwise keep options to a sensible minimum [21:04:24] <chrono325> good point :) [21:05:08] <chrono325> probably want to stick with 'update' then, since it is reasonable to allow some branches while disallowing others [21:05:18] <jpetso> agreed [21:05:27] <chrono325> or grant some users the ability create branches, but not to tag [21:06:10] <chrono325> and rather than making them re-push with a different set of parameters, just reject those that don't pass and let them know about it [21:06:27] <jpetso> yep. [21:06:28] <jpetso> are tags also being processed in pre-receive/update? [21:08:20] <chrono325> yup [21:08:24] <chrono325> as are deletions [21:08:30] <jpetso> nice :] [21:08:42] <marvil07> IMHO on dvcs, own branches/tags on upstream are really important to work independently, so maybe all commiters should be able to do that [21:09:28] <marvil07> well, the other option i work branch/tag on local and the pass patches :p [21:09:29] <chrono325> yeah, I think it would be interesting to be able to create, say a 'chrono325' branch on any project and push to there without restriction (within limits, maybe) [21:09:50] <chrono325> and then the maintainer of the project could decide to pull those changes into master [21:10:09] <jpetso> marvil07: imho it's the responsibility of the access checks to allow (or disallow) such branches [21:10:22] <chrono325> absolutely [21:10:47] <chrono325> that is what my July is going to be about, is multiple branches per project [21:10:53] <chrono325> and how to integrate that [21:11:04] <jpetso> personally, i wouldn't want anybody's branches in my official repo, as a maintainer i decide for myself what goes there and what doesn't [21:11:24] <jpetso> others can still create their own clones, and i can pull from those [21:11:33] <corni> chrono325: sorry was away, but why do you need to bootstrap drupal for every branch? has this to do with the access checking or the log parser? [21:12:10] <chrono325> corni: this is all about the access checker. I haven't started the log parser yet (that should be much more straightforward). [21:12:22] <corni> ah okay :) [21:12:22] <jpetso> chrono325: because the 'update' hook is called once for each ref, and we prefer 'update' over 'pre-receive' at this time [21:12:35] <jpetso> er, chrono325:/corni:/ [21:12:39] <jpetso> whatever. [21:12:48] <corni> lol [21:13:02] <chrono325> corni: since 'pre-receive' denies an entire push if just one ref is rejected, even if other refs are fine [21:13:13] <jpetso> imagine an s/ preceeding that pcre [21:13:35] <corni> yeah but is the history maintained correctly if you deny one commit but pull in the others? [21:14:06] <chrono325> But since the number of refs pushed is likely to be small, the cost of bootstrapping drupal each time will likely be smaller than other factors, like the time to push the objects [21:14:18] <chrono325> it's not per-commit, it's per-branch [21:14:39] <chrono325> and the correctness of one branch should not depend on the presence of a different one. [21:14:57] <chrono325> if that is the case, then that branch should have been merged into the main one [21:15:29] <corni> argh right [21:15:33] <jpetso> in terms of resources, Drupal might be a significant performance factor because Git is really fast [21:15:42] <corni> but we don't mind [21:15:49] <corni> why should we? [21:15:55] <jpetso> but as there's a straightforward way to optimize that, we don't mind [21:17:38] <chrono325> also, I think that things like initializing the git communication and uploading the objects will take longer than the drupal bootstrap [21:18:13] <chrono325> also, checking each path of each commit against whatever access restrictions are in place will probably take longer than a drupal bootstrap [21:18:28] <jpetso> i don't think that is the case. [21:18:36] <chrono325> though I'm mostly talking out of my ass, since I don't have any idea how long a drupal boostrap takes compared with other operations [21:18:38] <chrono325> :) [21:18:54] <jpetso> Drupal is a pretty complicated beast, and does a *lot* of things while bootstrapping [21:19:01] <chrono325> hmm [21:19:26] <chrono325> it should be fairly straightforward to run a benchmark testing how much overhead there is per ref push [21:20:04] <chrono325> write both a pre-receive and an update hook, push a bunch of refs to a repository, and see what the difference between the speed of update and pre-receive is [21:20:15] <corni> btw are rights checked when deleting/adding a branch? [21:21:13] <chrono325> that's up to the implementations of versioncontrol_write_access [21:21:40] <chrono325> for now, I pass the creations and deletions along to has_write_access [21:21:57] <chrono325> so you could add whatever you like on top of that [21:22:01] <jpetso> (regarding the benchmark line.) yeah. and really, we shouldn't break our heads about performance at this time... if Drupal can handle Drupal CVS then it will also handle the same amount of commits for Git repositories [21:22:38] <jpetso> and that's already a lot [21:23:01] <jpetso> chrono325: so the way i see it, work on the git hook scripts is going forward pretty nicely, apart from those "minor" issues, right? [21:23:47] <jpetso> chrono325: i'll be reviewing your SVN backend changes soon, and i've asked sdboyer to review the new-svnlib part of it [21:24:01] <jpetso> so that we can merge that asap. [21:24:25] <chrono325> jpetso: correct. I know how to move forward, I just spent a bunch of time moving down a deadend [21:24:47] <jpetso> cool, way to go [21:25:15] <chrono325> jpetso: I haven't done any real changes to new-svnlib aside from removing the old svnlib and importing the new one as a submodule [21:25:40] <chrono325> I don't think I touched it in my hooks or tests [21:26:15] <jpetso> chrono325: afaik sdboyer keeps a custom branch of svnlib in versioncontrol_svn [21:26:43] <chrono325> jpetso: oh really? I just used the one he has on github [21:27:08] <jpetso> chrono325: i think he said he did, but i'm not sure what's in there [21:27:17] <jpetso> chrono325: can't be a lot of changes in any case [21:27:39] <jpetso> but i need him to check this before committing any changes. [21:28:17] <jpetso> chrono325: plus an svnlib in versioncontrol_svn/svnlib/ coincides with the location of the old svnlib, and he imported the new one at new-svnlib (which i'm not a great fan of, but hey, whatever) [21:28:19] <chrono325> sure. I can certainly back out the update. [21:28:53] <jpetso> so i'll let sdboyer take control of anything regarding svnlib, and hopefully i can check in all the other changes [21:29:02] <chrono325> jpetso: yeah, I deleted the old one, as well as the contents of new_svnlib and imported his thing as a submodule at 'svnlib' [21:29:43] <chrono325> the only thing to be aware of is that I made a change in versioncontrol_svn.module to make use of the new svnlib path [21:30:28] <chrono325> changed an 'include_once' from 'new_svnlib/svn.php' to 'svnlib/src/svn.php' [21:30:39] <chrono325> so if you do use the older structure, make sure that doesn't slip in [21:30:53] <jpetso> chrono325: could you perhaps open an issue pointing to your branch on Github, so that i can include it in the (modified) commit messages? [21:31:18] <chrono325> with or without the svnlib changes? [21:32:02] <jpetso> chrono325: just something saying "i did this cool branch on Github [here], please merge the commits" [21:32:17] <chrono325> jpetso: k :) [21:32:30] <jpetso> chrono325: in order to reference the issue id, like "#12345 by chrono325: (blah blah blah)" [21:32:53] <chrono325> jpetso: got it [21:33:39] * jpetso just saw that cvsexportcommit can prefix the commit messages with some user defined string, YAY [21:35:35] <chrono325> jpetso: what does that buy us? [21:36:16] <jpetso> chrono325: i can commit your commits with "#12345 by chrono325: " prefixed without rebasing and altering all the commit messages [21:36:18] <marvil07> autoinclude "#" that's is the comment identifier by default in git commit messages by editor [21:36:47] <marvil07> :o [21:37:00] <jpetso> marvil07: i had that issue last time, can be worked around with -m "commit message" instead of invoking the editor [21:37:20] <chrono325> ah, I see [21:37:28] <chrono325> cool, attribution ftw! [21:37:47] <jpetso> ok, i think the chrono325 side of today's meeting is pretty much covered [21:37:55] <chrono325> well, I have one more thing [21:38:02] <jpetso> ah, sorry [21:38:49] <chrono325> It may be kind of moot (because of how I'm going to do the post-receive hook), but I was a little unclear about the 'source-items' property of $operation_items [21:39:14] <corni> can we postpone this? i've a bit to say about them, too [21:39:15] <corni> :D [21:39:22] <corni> a bit more general, though [21:39:40] * jpetso mentally prepares for that bullet point [21:39:56] <chrono325> it was mainly about how and whether to fill them in, since it isn't totally clear from the docs. [21:40:42] <chrono325> jpetso: oh, btw, here is the issue http://drupal.org/node/491544 [21:40:43] <Druplicon> http://drupal.org/node/491544 => Add hook scripts to subversion => Version Control API -- Subversion backend, Code, normal, active, 1 IRC mention [21:40:58] <jpetso> chrono325: great. [21:41:38] <jpetso> source items are indeed a point of worry, they're causing significant slowdown for the SVN backend and make things hard for DVCS as well [21:41:52] <jpetso> although dropping them is not really an option imho [21:42:49] <chrono325> the main thing I'm unclear on is exactly what gets added to the array [21:42:53] <jpetso> my favorite pipe dream is deferring the recording of source items to whenever we've got time for it [21:43:07] * marvil07 thinks it seem to be the good time to talk about dww comments because of his suggesiton about removing source items form vcs core api, did I missunderstood somthing corni? [21:43:11] <chrono325> and if I need to include _all_ previous items or just the most immediate previous one [21:43:23] <corni> marvil07: no i don't think so [21:43:36] <jpetso> chrono325: just the immediate previous one(s) [21:43:49] <jpetso> chrono325: (s) in case of merges [21:43:55] <chrono325> jpetso: ah, that makes things SO much easier :) [21:44:11] <jpetso> everything else would be insane [21:44:28] <chrono325> jpetso: ack, more complication :(. That means I need to remember if the current commit is a merge and deal with that stuff. boo. [21:45:04] <chrono325> jpetso: and are the values items or just the vcs-specific identifier? [21:45:15] <marvil07> I see a merge flag in some place :p [21:45:32] <jpetso> marvil07: that won't help a lot with finding out about merges altogether [21:45:40] <jpetso> chrono325: items [21:46:09] <jpetso> chrono325: which identifier would you be using for that purpose? [21:46:10] <chrono325> jpetso: so that means I need to pull out the item at that path in the previous commit(s). Got it [21:46:32] <chrono325> jpetso: I don't know, I just wanted to make sure of the format. [21:46:47] <jpetso> chrono325: that's the main point of critique regarding source items, in fact [21:47:01] <jpetso> chrono325: you shouldn't be required to pull that item, but currently you are [21:47:06] <corni> jpetso: why do we need the source_items in the _core_ api? wouldn't they make sense as an additional requirement, before you can use the repoviewer/commitlog [21:47:37] <jpetso> corni: if you haven't even got commitlog, what exactly do you have? [21:48:02] <corni> jpetso: stuff to insert commits, and btw http://drupal.org/project/cvs/148301 doesn't show the prev commit which modified that file(s9 [21:48:04] <corni> *(s) [21:48:30] <corni> i don't think you really need that info anywhere [21:48:56] <jpetso> corni: yes it does, look at the revision link leading to the diff [21:49:40] <jpetso> corni: but overall, i agree it shouldn't be necessary to fetch from the beginning [21:49:58] <corni> jpetso: still, imho it's up to the repo viewer to implement a thisrev=bla&otherrev=prev [21:50:07] <corni> so it's not our job to get that revision [21:50:28] <corni> and something like that: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/drupalorg/ drupalorg_project/drupalorg_project.info?view=log [21:50:36] <corni> is up to the repoviewer, to get the file history [21:50:48] <jpetso> corni: hand me the patch to make it optional and an API to fill it in at a later time, and you're my personal hero [21:51:13] <jpetso> we're currently totally lacking the latter [21:51:22] <corni> jpetso: the personal hero? :P [21:51:51] <jpetso> corni: like, the one who resolved the single remaining performance issue for all non-CVS backends [21:52:00] <corni> i'm sure marvil07 wants to step in and do this while he does the OOP conversion ;) [21:52:14] <jpetso> good point :P [21:52:27] <marvil07> yep, another interface [21:52:35] <corni> just as the access resctrictions are optional, this could be optional as well [21:52:41] <corni> + lazy-loading if wanted :P [21:52:59] <jpetso> at this point, i suspend the source items discussion and head over to marvil07's project [21:53:04] <chrono325> god, objects and lazy loading would make my day as well [21:53:14] <corni> lol [21:53:17] <chrono325> marvil, you are truly a god among men :D [21:53:28] <jpetso> where, admittedly, improvements to the source items mechanism are subject to later work [21:54:08] <jpetso> k! so! how's it going, marvil? [21:54:43] <jpetso> both you and chrono325 posted the last SoC-specific Twitter/identi.ca updates on Tuesday, iirc [21:54:56] <corni> i'm afk for ~10mins, i don't think you really need me atm :) [21:54:56] <marvil07> I've just pushed some commits on my oop branch of versioncontrol and versioncontrol_git at github [21:56:07] <marvil07> Converting to oop is taking me really more thatn I though :( [21:56:49] <jpetso> marvil07: yeah, i should have expected it to be more difficult. two weeks was very optimistic. [21:58:00] <marvil07> well, like you infer I'm using git backend like my test case [21:58:53] <jpetso> marvil07: what's your current estimate on when the OOP conversion will be working (1), or done (2)? [21:59:58] <marvil07> I hope 2 weeks more than I schedule [22:00:03] <jpetso> marvil07: and second, what issues are you currently facing? [22:00:24] <marvil07> welel [22:00:29] <marvil07> fisrt [22:00:34] <marvil07> I used arrayaccess :D [22:00:49] <marvil07> and it _really_ makes all better :D [22:01:11] <jpetso> told you :] [22:01:39] <marvil07> I named tables id's [22:01:43] <marvil07> as _id_ [22:01:43] <marvil07> id [22:02:32] <marvil07> but looking actual implementation it use repo_id vcs_op_id [22:02:37] <marvil07> so, I need to change that [22:03:11] <marvil07> I also see "_" functions used outside it's files think :p [22:04:48] <jpetso> as a side note, methods named _blah() don't make a lot of sense as we've got public/protected/private access modifiers anyways [22:05:15] <jpetso> so instead of _blah(), just have them private function blah() and be done [22:05:45] <marvil07> I think it really explicit its visibility :D [22:06:54] <jpetso> well... anyways. not that big of an issue, even if i think sdboyer might agree on that with me [22:07:01] <marvil07> well, main work was on seeing where is arrays passing and changing them by objects [22:07:43] <marvil07> s/is/are .. :p [22:08:49] <marvil07> I remeber! something on desing [22:09:12] <marvil07> I talked with sdboyer on tuesday about that [22:09:22] <jpetso> last week, i encountered an issue with ArrayAccess which entails that "$arrayObject[$foo][$bar] = $blah;" doesn't work if $arrayObject[$foo] is accessed by offsetGet()/offsetSet() [22:09:50] <marvil07> :o [22:09:51] <jpetso> but that should be a minor problem, especially since the arrays are getting replaced anyways [22:10:41] <jpetso> (mind that "$arrayObject[$foo] = array($bar => $blah);" does indeed work.) [22:11:07] <marvil07> we agree on using arrays on "parent objects" as well as references to parents on childs (I mean repository - operation relation by parent-child) [22:11:31] <marvil07> but I end up using only references on child [22:12:19] <jpetso> well yeah, one repository per operation doesn't require an array, no? [22:12:36] <marvil07> ? [22:12:47] <marvil07> sure [22:13:05] <jpetso> or probably i misunderstood the above statement [22:13:32] <marvil07> I mean I'm only using repository member on operation class and _not_ an array of operations on repository [22:13:42] <marvil07> class [22:14:06] <jpetso> oh, right. yeah, that's most probably a good thing [22:17:28] <jpetso> marvil07: so what's next up on the OOP front, and what do you plan to get done until next week? [22:17:45] <marvil07> I didn't find whre I posted about my problem.. maybe I didn't :( [22:19:00] <marvil07> I'm now trying the basic workflow works with the git backend [22:20:15] <marvil07> the problem I mentioned was that I didn't find the reason why I'm "going nowhere" at edit and delete repo actions on repo's page [22:20:57] <marvil07> I left that after some time on tuesday, then work on fetch action [22:21:03] <marvil07> and now still there :( [22:21:19] <jpetso> marvil07: is there something i can help with? [22:21:27] <corni> marvil07: how do we handle stuff i change in the 6.x-1.x branch of vcs_git which should get trhough into the oop version? [22:21:36] <corni> marvil07: you rebuilt the menu? [22:21:51] <corni> marvil07: i had non-working links for expample caused by this [22:22:38] <marvil07> I'm applying all your changes on my master and my oop branches [22:23:05] <marvil07> your(I mean jpetso) [22:23:25] <marvil07> I remeber another thing :d [22:23:48] <marvil07> In my master branch I also pplied a little change [22:23:58] <marvil07> for 6.x branch [22:24:32] <jpetso> i noticed, and committed that into CVS shortly before this meeting began [22:25:29] <jpetso> if you remember (or look above), that commit was the one i referred to when i complained about combining Git and CVS history [22:25:45] <marvil07> :o [22:25:58] * marvil07 fetching [22:26:15] <corni> jpetso: why don't you leave the d.o cvs except for releases and use github for development? [22:27:20] <jpetso> corni: i don't know if it's a good idea to drop CVS like that, i mean, we're a bit of a high-profile project and a showcase for good Drupal development [22:27:38] <jpetso> corni: what about you ask dww on his opinion on that matter? :P [22:28:07] <corni> jpetso: hahaha, but you will at some point make a mistake which will either screw cvs or git :P [22:28:19] <jpetso> corni: well thanks for the encouragement :P [22:28:28] <corni> jpetso: so's life ;) [22:28:41] <marvil07> lol [22:29:06] <jpetso> do you people have problems when the resulting commits are different (rebased) from the ones that you originally committed? [22:29:21] <jpetso> i mean, i would guess so, but no idea on how to go about it [22:29:25] <marvil07> jpetso: I do not see the commit you mention on your master at github :(, is it there? [22:29:33] <jpetso> marvil07: oh. crap. [22:30:04] <corni> i don't know, but i guess i've to rebase or re-create the entire vcs_git repo, it contains files it definitly shouldn't contain back in the history [22:30:44] <jpetso> corni: i'd say versioncontrol_git is, er, doomed, so it might just stick with Git [22:30:56] <marvil07> jpetso: rebase rewrite commits ..(I miss somethig maybe) [22:31:09] <jpetso> corni: plus it's *the* Git backend, and thus has a good reason to go missing from CVS [22:32:27] <jpetso> marvil07, chrono325: btw, your wiki pages are *slightly* outdated [22:33:18] <marvil07> :p [22:33:46] <jpetso> corni: i'd rather keep Version Control API itself true to the "Drupal way", especially since dww will chime in as co-maintainer once it's on d.o [22:33:55] <corni> jpetso: okay... [22:34:48] <jpetso> marvil07, chrono325: also, can i please get daily status messages again? they're just soooo cute. [22:36:25] <jpetso> marvil07: be aware that if you change vc_op_id to id and author to committer, drupal_write_object() won't work as expected [22:36:42] <marvil07> I know jpetso , I'll try :D, but my problem is that for example today I make the commits, because I had all-break site in this week [22:37:13] <marvil07> yep jpetso I was thinknin in change id names to the tables one's [22:37:22] <chrono325> jpetso: sounds good, I'll start them back up [22:37:48] <jpetso> marvil07: i don't need daily pushes, just would like some updates on what happens. nevermind the outcome. [22:38:25] <marvil07> ok [22:38:48] <marvil07> well, comming bakc to the main theme [22:38:55] <jpetso> k [22:39:40] <marvil07> my plan this week is to make oop work! :p, it's difficult to cut off this target in little pieces :( [22:40:03] <marvil07> at least the basic workflow [22:40:23] <marvil07> add/edit/delete/fetch repo [22:42:09] <jpetso> that would be awesome, if that part works then we should be nearly there (hopefully) [22:42:31] <marvil07> I hope so :p [22:44:00] <jpetso> chrono325: versioncontrol_svn's hooks branch is the same as master, isn't it? [22:44:09] <jpetso> chrono325: just so that i don't pull from the wrong one [22:44:14] <chrono325> yeah, I merged them [22:44:20] <chrono325> so my master branch includes my hook branch [22:44:52] <chrono325> jpetso: I cleaned up the history a bit, but kept the original (dirty :) history in hooks-historical [22:45:53] <jpetso> chrono325: yeah, you wrote that in your merge request [22:46:15] <jpetso> chrono325: cleaned-up history is a major coolness, btw [22:46:51] <chrono325> jpetso: thanks. I'm kind of a neat freak when it comes to histories. I want everything to look all nice and pretty in gitk [22:47:30] <corni> any advice how i can remove the history of an old branch in the vcs_git repo without screwing your forks+clones? [22:48:59] <chrono325> corni: well, if it is already published and we have based stuff off of it, there's nothing you can do [22:49:21] <corni> yeah, that's what i've thought [22:49:36] <chrono325> corni: if nobody else has seen it yet, a combination of git rebase -i (which is my personal lord and savior, btw) and git filter-branch will do it [22:49:42] <corni> then you can find a whole d6.10 install in your git repo for vcs_git ;) [22:50:00] <chrono325> corni: yeah, I saw that :) [22:50:10] <corni> replacing all repos (again) is nothing i like to do [22:50:40] <chrono325> corni: if it was important enough, we could all agree to clean up the history and start over with a new one. It would invalidate all of our current branches and tags, but it would clean the history [22:50:55] <chrono325> corni: unless it were really dire, I think that wouldn't be worth it. [22:51:15] <marvil07> yep! [22:51:19] <corni> :D [22:51:42] <corni> it bloats the repo though :( [22:52:02] <chrono325> true, but it probably isn't by that much [22:52:14] <marvil07> rebase rewrite comits, so we should have to rebase our branches anyway [22:52:21] <corni> the repo is >1MB [22:52:50] <chrono325> for me, with both jpetso's version and corni's, it is 2.9M, uncompressed [22:53:06] <jpetso> chrono325: i'll be deleting my version right now [22:53:15] <jpetso> sorry for not having done that earlier on. [22:53:20] <chrono325> and it's 1.5M compressed. [22:53:47] <chrono325> so it's a bit of wasted space, but with internet bandwidth as it is, probably not that big of a problem [22:54:09] <chrono325> plus, once you've downloaded it once, the old stuff doesn't affect you anymore [22:54:17] <corni> i don't have a password in there (i checked) so we can leave it... [22:55:32] <corni> anything important still not discussed? [22:55:36] <marvil07> well not a real problem, but it _the_ git backend git repo, so I would really appreciate if it's clean :p [22:55:45] <corni> I'd like to go to bed [22:56:04] <corni> marvil07: you're the one who'd have to adjust/recreate your repo [22:56:24] <corni> I can fix+replace the vcs_git repo, will be a good git exercise :D [22:56:27] <jpetso> personally, i'm fine with today's outcome, no bullet points left from me [22:56:56] <marvil07> ok [22:57:02] <chrono325> I think that's about all I've got as well [22:57:24] <corni> i'll tell you guys when i rewrote the repo, so you can clone (the hopefully last time :D) from there [22:57:35] * marvil07 wiuld try it's best this week.. you vsc api :p [22:57:40] <corni> or shall i wait for the merge from chrono325? [22:57:44] <chrono325> I will say, though, that if we are going to change the repo, we should do it soon, before too many people depend on it [22:57:45] <corni> would be probably easier [22:58:04] * marvil07 have a problem with its keyboard on another languages :p [22:58:43] <corni> chrono325: when do you think you're done with the commit hooks, so i can merge them+recreate the repo after i've done so? [22:58:47] <chrono325> corni: my stuff can just be rebased on whatever you end up with. It is pretty isolated from anything else, especially if the api doesn't change [22:59:16] <corni> chrono325: ok then i'll do it whenever i've got some free time :) [22:59:24] <corni> notices will be send out by druplicon ;) [22:59:31] <marvil07> cool corni ! [22:59:32] <corni> +maybe a d.o issue [22:59:51] <chrono325> corni: If I get good work done in the next few days, I could probably have it done by Wednesday, or even Tuesday. I'm still dealing with the apartment I just moved into, so that occasionally eats up time [22:59:55] <corni> marvil07: just do your work, it's ways cooler than mine ;) [23:00:22] <skiquel> chrono325: word [23:00:23] <chrono325> corni: if you want help with the rewriting of history, I have experience doing that (with my own stuff) [23:00:31] <corni> chrono325: no problem, when i do it before you're done you've just to rebase, but that's no issue :) [23:00:58] <corni> chrono325: i should figure it out alone to see how hard it is to get - so i know what i sell when i advise git for contrib/ :D [23:01:08] <corni> but thanks for your offer :) [23:01:30] <chrono325> corni: No problem. If you get stuck or need advice, the offer stands :) [23:01:56] <corni> :) [23:02:40] <marvil07> well, good to be here :D [23:02:50] <marvil07> thanks for your time guys [23:03:02] <jpetso> thanks for YOUR time, guys [23:03:06] <marvil07> time to lunch now, see you soon by here ;) [23:03:21] <corni> good night then :) [23:03:30] <chrono325> if there isn't anything else, I have a bedframe to move into my apartment :D [23:03:34] * jpetso needs to remember to visit #drupal-vcs more often [23:03:35] <corni> lol [23:03:45] <marvil07> :D [23:03:53] <jpetso> well, have a great evening y'all [23:03:58] <corni> at least you visit every sunday ;)