----- "Jesse Keating" <jkeating@xxxxxxxxxx> wrote: > I'm working on fixing a few long standing bugs in fedpkg that have to > do > with our branch structure > (https://bugzilla.redhat.com/show_bug.cgi?id=619979 and > https://bugzilla.redhat.com/show_bug.cgi?id=622592). > > This has me examining our branch structure again and trying to > remember > why exactly I chose it (obviously I did a poor job of documenting > that...). > > The original thought was to have top level branches that are named > after > distribution releases, eg "f14", "f15", "el5". Then we would force > branches of those branches use a naming structure of "f14/topic". > The > reason was so that our tooling could look at the name of the branch > and > easily work back to the "f14" part. This would work even if it was > "f14/user/fred/topic/mybranch" or other such craziness. When I went > to > test this, I realized that git won't allow you to have both "f14" and > "f14/topic" as branches, because of the way the git metadata works on > the filesystem. When I encountered this, I made "f14/master" become > the > top level branch, and then "f14/somethingelse" could coexist. > Unfortunately I also wanted to keep things easy for users and tried > to > maintain tooling that would allow you to just say "f14". This didn't > get enough real world testing and in hindsight was a bad idea. > Things > go wrong quickly in git if your local branch name doesn't match the > remote branch name. > > When thinking about the above, and the two bugs I'm working on, I > realized that we don't have any real strong need to be using "/" as a > delineator. It makes some code easier, but makes other things more > complex and difficult. So what if we changed it? > > What I'm thinking about now is switching from / to - as a delineator. > This would improve a couple things. First, we could achieve upstream > top level branch names that are short and simple: "f14", "f15", > "master". I'm all for this change. I believe the majority of users will have an outcome with f14/f13-kind of branches. > We can have branches that build upon those names: > "f14-rebase", "f15-cve223", "f15-user-jkeating-private". We could > keep > the simple fedpkg tooling that allows users to just type "f14" and > the > like to reference a branch, and now the local branch will match the > name > of the remote branch. > > As for the first two bugs I mentioned, it doesn't directly help them. > However I would feel better about telling people that their local > branches must follow a naming scheme of <release>-<something> and > then > we could easily guess what release the local branch is for if it > isn't > tracking a remote branch. However the bug about what to do if there > are > no remote branches is really not touched by any of this, it just got > me > thinking about branches :) > > What kind of user impact would this have? > > My hope is that the impact would be minimal. Git allows branch > renames, > and can successfully rename "f14/master" to "f14". All the history > is > renamed. We should be able to do this without an outage of the git > server. > > The ACL system will need a slight tweaking, and a regeneration of the > ACLs but that is fairly quick and minor to accomplish. > > However there will be some issues client side. We will not be able > to > make use of git's symbolic-ref feature of "aliasing" a branch. We > cannot make "f14/master" an alias for "f14", again because of the > filesystem layout issues. These issues rear their head once again > when > a client does a pull of an already checked out repo that had > branches. > Because there was already a f14/master, when the client sees a new > branch just named "f14" it will fail to create it. Git has a command > that will fix this "git remote prune origin". That will remove the > local reference to f14/master and a subsequent pull sees the creation > of > the "f14" branch happen successfully. However, if a user had a local > branch of f14 or f14/master they will be left with mismatched > .git/config entries. In this case it's easiest to delete the local > branch (git branch -d f14) and check it out again. If there are > changes > on the branch one can fix the config to point it to the right > upstream > location. > > Also we would need to get a new fedpkg into the hands of all the > developers that handles the new branchnames. We could do a build > that > handles both the oldnames and the new and have it out and available > for > a reasonable period of time before we make the switch. Would it make sense to add functionality to fedpkg which checks if there exists configuration for remote branch tracking (i.e. local "f14" tracks remote "f14/master"), and if that's the case, print a warning (e.g. that it's recommended to delete the local branch and recreate/check it out again)? This won't help much for the "git pull" problem, but it may prevent some users from running into that problem in the first place, because they saw the warning earlier when switching branch or doing some other fedpkg operation. --Severin > So, some pain, for some pretty good gain. This time around I can > setup > pkgs.stg with this branch configuration and builds of fedpkg to use > it > for a more through testing before rolling it into production. > > So please, tell me what you think! > > -- > Jesse Keating > Fedora -- Freedom is a feature! > identi.ca: http://identi.ca/jkeating > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
