Port to 6.x

Waiting on versioncontrol port to 6.x.

Patch contains a/ b/ in front of all file indexes. I can bypass that, but then it still doesn't apply.

Please re-roll.

:o

weird error patching info file(I suppose the problem is automatic changes with CVS :p), now it applies naturally

Not trying to be anal, but I get rej:

Well, it would be recommended to roll against HEAD as that is for 6.x dev, but DRUPAL-5 and DRUPAL-5--1-2 are all the same...I tried all three with same result.

The second patch posted is virtually identical to the first other than a hash change, not sure if you meant to upload a different file?

After quick discussion in IRC I agree that since I have no time for this now and marvil07 is interest I have given him CVS rights to develop 6.x branch.

Look forward to seeing results.

Great! Some comments on the patch:

• db_last_insert_id() is not the same as db_next_id() - the latter retrieves a value for the next insert, whereas the former retrieves the value for the insert that happened just before. As you haven't done an insert query at that point yet, the db_last_insert_id() function is going to hand you an incorrect id. The proper way would be to use drupal_write_record() without id property (and with an empty $update array, so that it runs in insert mode) - that function automatically takes care of handling db_last_insert_id(), and fills the passed array or object with the actual new id.
• The 'access callback' property for the menu entry can be left out if the callback is 'user_access', as that is the default anyways.
• The "global $user;" line can be removed from hook_menu() too.

Apart from that, I can only refer to the FakeVCS, CVS and SVN modules - if you need any examples, much of the required code exists in an approximately similar way in those other backends. Thanks for starting the port, and good luck!

Oh, and one more thing: I finally got around to putting some documentation into the handbook, you might want to have a look at that.

@boombatower: yup, I saw that, and I'm also subscribed to the commit feed so I notice when something happens there :)

I'd love to help - I added the missing functions(from 5.1.x to the git 6.x-dev), but that just makes it more like the old version (so that's wrong). jpetson, can you give an example (or where to find an example) of how to make a commit log when you have dropped the {versioncontrol_git_commit_branches}, {versioncontrol_git_item_revisions}, {versioncontrol_git_item_tags}, {versioncontrol_git_tag_operations} and {versioncontrol_git_item_source_revisions} tables? I searched the versioncontrol_fakevcs and there is very little mention of the commit log. What function would be used? marvil07 - any updates I can work from? Thanks!

subscribe, also interested in helping here!

Ok, let's have some more notes:

• versioncontrol_git_get_label_id() shouldn't be required - instead, you can create a label array (e.g. array('name' => 'master', 'type' => VERSIONCONTROL_OPERATION_BRANCH)) and pass it to versioncontrol_ensure_branch(), then the return value label array will contain the 'label_id' element.
• Don't waste time on porting versioncontrol_git_commit() and versioncontrol_git_get_commit_actions() - those functions will be removed anyways after the $commit/$commit_actions arrays have been converted to $operation/$operation_items format. Converting the log parser to generate arrays in that format is probably the best thing you can do in order to get noticable results (= commits that show up in the commit log) in the fastest possible way. Some code in versioncontrol_git_commit() and versioncontrol_git_get_commit_actions() might be useful for that, but the bulk of it is already in Version Control API itself.
• Functions you can delete right away - because they're now moved to / handled by the API module, and the current functions in the Git backend don't include valuable code - would be _versioncontrol_git_get_item_revision_id(), versioncontrol_git_tag_operation(), versioncontrol_git_get_source_items(), versioncontrol_git_get_commit_actions() and versioncontrol_git_get_item_revision(), versioncontrol_git_get_parent_item(), versioncontrol_git_get_commit_branches(), versioncontrol_git_get_directory_item(), and versioncontrol_git_get_commit_statistics(). I checked those, and you won't need any part of them later. (I also think they're not called from any functions that you didn't uncomment, so the backend should run just the same after the functions have been deleted.)

Anyways, dudes, you rock. go go go!

@Cornil: Like I said above - I specifically checked the functions listed above, and you won't need them as reference later. They're now just bloat. Note that I didn't list all functions that will be removed in the end, because some others actually might be handy as a reference.

imho, the port to D6 is pretty complete and working. Code is supposed to be comitted to cvs.d.o by marvil07 soon, else you can find it here:
http://gitorious.org/projects/versioncontrol_git
there's also a wiki page with a roadmap and a bit text of what i've done till now. If boombatower/jpetsp agrees that the port itself is done, please close the issue, we'll then open further issues for the roadmap points :)

Automatically closed -- issue fixed for 2 weeks with no activity.