I have a Git repository for a module with two branches (6.x and 7.x). I have tags on each of the branches. When I run drush fserver-update, I get a release for each of the tags, but the files all appear to be built from the 7.x branch.

CommentFileSizeAuthor
#5 fserver-1185366-5.patch868 bytesdanepowell

Comments

eugenmayer’s picture

eugenmayer commented

Well i guess head is used? In my undestanding, a tag is just a pointer to a commit. A commit is unique and identifies the branch or a branch-cross by that manner - so there should be no need to have something like "tags for branches" - tags are unique by definition?

danepowell’s picture

danepowell commented

Yeah perhaps my terminology is wrong and it's just pulling from HEAD rather than from the revision associated with the tag. Still bad though :)

danepowell’s picture

danepowell commented
Title: Git tag doesn't match branch » Git fails to checkout tag, generates packages from head

I think this is because in FserverProject_git->create_package (line 385), you need to specify --work-tree in addition to --git-dir. See http://kerneltrap.org/mailarchive/git/2008/4/29/1667244, and also possibly https://github.com/developmentseed/FeatureServer/pull/7

I say this because I noticed that if I run drush fserver-package --v, then copy and run the generated git checkout command, I get error: You have local changes to '<package_name>.info'; cannot switch branches. But if I cd into the tmp git working directory and run git checkout, it works just fine.

eugenmayer’s picture

eugenmayer commented

Dane, AFAIR there are issues with --work-tree. E.g. i know that if you call "status", you are not allowed to use work-tree, but only git-dir, for a push, you need us --work-tree. Also work-tree is not avail in older git releases ( but i guess we should not care about that to much ).

For my vote, we just need to test all the git-commands happen ( those are just pretty few ), with and without git-dir / work-tree int he console to see, what should be there when. Overall, those --work-tree should be included here, makes sense

danepowell’s picture

danepowell commented
Status: Active » Needs review
StatusFileSize
new fserver-1185366-5.patch868 bytes

Well it's just that one command (checkout) that needs to specify --work-tree. Here's a patch that adds that. Everything works swimmingly with this patch in place!

eugenmayer’s picture

eugenmayer commented
Status: Needs review » Patch (to be ported)

I see, thats pretty straight forward. Thanks for testing it Dane, lets take that one into the next release.

danepowell’s picture

danepowell commented
Status: Patch (to be ported) » Reviewed & tested by the community

Did you mean to mark this 'to be ported'? I think it should be RTBC...

eugenmayer’s picture

eugenmayer commented
Status: Reviewed & tested by the community » Patch (to be ported)

Well to be ported means, that the maintainers takes a note to include the patch - so its after RTBC :) "include in the next release - patch is ok"

danepowell’s picture

danepowell commented

Oh... my understanding of PTBP was if you have a working patch for one branch and need to backport it to another branch. I guess people use it differently.

eugenmayer’s picture

eugenmayer commented

i guess so ( if you look at the order in the dropdown box, it seems it has been ment that way - but who actually cares )

eugenmayer’s picture

eugenmayer commented
Status: Patch (to be ported) » Fixed

applied, will be part of 1.2

eugenmayer’s picture

eugenmayer commented
Version: 6.x-1.1 » 7.x-1.x-dev
Assigned: Unassigned » randallknutson
Status: Fixed » Needs work

moving to the 7.x dev branch to get backported

eugenmayer’s picture

eugenmayer commented

well, that patch is not enaugh actually ... we have a side-effect here. ( took me some time to get this out of that crappy code :/ )

- first i changed the init_wc method to actually use the --mirror trick. This ensures, that every ref gets fetched ( as tags can be on every of those )
- then, when you have more then one package generated for one ( the same ) projects, the old code actually
- dublicated info-file ( see http://drupal.org/node/1183200 )
- as the wc gets changed during the info-file manipulatiot, the 2nd and every else package of a different ref cannot change the branch / ref..as the wc is modified
- so as a solution, we actually reset --hard after each turn of generation, to leave the repo in clean / initial state

As it took me a while to get a clue here, the patch is not very clean. In addition it includes
- a fix for the body to not use LANGUAGE_NONE as it is not set
- a fix for the tag-message being a proper string
- a proper block for the automated added info-string $packaging[] = "; <- FSERVER AUTOMATED AREA //START ->"; and $packaging[] = "; <- FSERVER AUTOMATED AREA //END ->";

iam not going to split this up into several issues, since the code is far away from stable (and i dont got no nerves left for today)

See commit 40c64c3 for the diff / cherry pick. Got releasen in 6.x-1.2-beta2

eugenmayer’s picture

eugenmayer commented
Status: Needs work » Postponed

for now, postponing all all D7 issues, as the branch seems unmaintained by the initial author. PLease suggest using D6 rather for now