-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to git (update links etc) #18
Comments
tl;dr If we manage to dcommit successfully and share the git svn config for this repo we can plan carefully the move - we will be working entirely here and just dcommiting to svn Longer version: Things that need to be done:
Those need to be investigated by someone Related questions http://stackoverflow.com/search?q=user%3A281545+[git-svn] Please realize this must be done carefully - so we can preserve the history - both to give credit where credit is due and to be able to bisect/blame/track history. As I see it : keep the SVN (till we are ready, which includes moving the trackers etc etc) only for dcommiting from here - so users can download their code from there @WrinklyNinja wants to help - please wrinkly try to answer the above I'd rather avoid using some git2svn tools because I want this to be done 100% correctly (those tools might have defaults or config options that are not obvious and skip stuff) - but I am not against either Please again - I have spent a lot of time on this and it is not exactly elementary I quote a post from the threads - see there for discussion (the discussion really started on the summer of 13)
|
Questions
Opinions:
Sorry if I'm being short, I've had an absolutely terrible week IRL. That doesn't change my thoughts on this though, so hopefully I'm still expressing them well. |
I'm still a little confused myself as to why we need to be able to push back to the SVN, too. The git repo has the complete history for the master branch of the SVN it looks like. What is left to preserve, other than branches/tags? I know I don't have the experience looking into this stuff, but to me it seems:
What am I missing that's in the SVN that we still need to bring over? The way it is right now I'm only comfortable pushing to my branch here, sounds like the same is true for wrinklyninja. |
This repo contains a bit of cruft but if it's ok with you then follow lojack's 123 procedure and finalize the port. I pushed @WrinklyNinja 's commits without the committed binaries into b304.4 as I said Posted a transcript of my experience here: https://github.com/Wrye-Bashers/wrye_bash_refactoring/wiki/Rebase-and-push-to-b304.4 - git tips in the wiki are +1 Renamed this issue - it's on you, I will be having little time for some days Bye SVN |
My post really was a "please explain to me why". Didn't mean to come off as overly pushy, but if there's good reasons not to finish migrating I really do want to hear them. I just don't see what they are at the moment, so I don't know if that's due to lack of experience of if there really aren't things that need to be done. |
@Utumno: The wiki page you posted - am I right in thinking that you rebased Also, I echo Lojack's sentiment. |
Also, one thing I've noticed is that the SVN's tags haven't been transferred to Git. I propose that we just do this without using git-svn, as there aren't that many tags, and all we need to do is tag the right commits, which we can search for using I discovered this while trying to do a git-svn of the Also, since this probably fits better here than in #7, I've been reading up on rewriting history, and testing it out on a local clone of this repository. I won't push my changes until everyone's happy with what is being done, so first a bit of explanation. First off, I'm basically following the instructions here, since although I've read around, they seem to be the best. I'm ignoring the part about amending Now, while I'm rewriting history, I also want to remove any large files that might have been committed by accident, either in the Git repo (like I did) or back in the SVN. I've found this, but haven't tried anything out yet. So actually, the stuff I am trying to remove from history is:
My reasoning for not rewriting out the I'm also slightly unsure how all this history rewriting will affect everyone's branches. I think I'm running the history rewrites on all the branches, so if I were to push this, it would replace everything on the repo, and nobody would experience any issues unless they have local branches or commits they haven't pushed. The possibility of such local edits is another reason why I'm being cautious. So, does this all look right to everyone? |
@WrinklyNinja :The tags are here but as branches - not sure it's so easy as this though
@lojack5 : reasons are there is a way to do this right. Right means all and only relevant history. Filter-branch may do this - I was thinking of carefully recloning the thing but whatever (lack of experience). Also takes time to redirect here - but If everyone feels confortable with git and you are willing to update posts and links and make SVN read only please go ahead |
@Utumno: Could you link me to a tag? I can't find them anywhere... The reason I'm trying to use OK, I tried using a couple of Python scripts to get the largest files in the history, but they didn't work for some reason, so I took the easy route and use GitExtensions to list them. This gave the result that the complete list of paths to remove from history is:
If only there was a way to do them all at the same time, because it takes a while to scan through history... Also, I asked @Sharlikran which of his branches he wants to be preserved, and he said the |
@WrinklyNinja:
I'll try my hand first at making the wiki page for unicode guidelines, then I'll see how hard it is to make a new repo for the forum posting stuff. I get the feeling I have no idea how to do it and have the history for those files retained. @Utumno: when you say all and only relevant history do you mean we have too much history at the moment (because of all the extra cruft in the SVN), or are we missing history (like from Tags)? |
@lojack5: I've already made a wiki page for the unicode guidelines. 😄 Thanks for the info on the stuff in So I'm trying to add only Sharlikran's 305 branch in the SVN to the Git repo, and I've figured out the following method:
I also did the same with his |
Ah, didn't notice the wiki page! I'll clean it up then, as the original text probably could use with some rewriting anyway. In that case, totally good with destroying Let me know what you figure out with the git-svn stuff. If you want to handle moving the forum stuff that's fine, otherwise I could always stand to learn it myself. |
One other thing I've noticed is that for Sharlikran's branches (which are the only ones that are being transferred from the SVN - I manually recreated mine here), they are orphaned, which means when I push them, everything needs to be uploaded (nearly 30 MB). This can't be good for the repo size, so I'm giving them "foster parents", tying them to the equivalent commit in |
Probably line endings? Since there's no .gitattributes whatever your default git config is doing for line endings probably isn't matching up with what was already there. That' my guess. |
Oh, I hadn't thought of that... Anyway, I managed to fix the enormous diff issue in I tried the same as 305, but that didn't work out because 305 has nothing after the problem commit. So I just removed that commit and pushed the branch. OK, so now what is left to do is:
I'm happy that I know the procedure to use for both. What I'm probably going to do is create a new repository in the same organisation as this one, so that just in case my changes screw something up, we have this to fall back to - although I've been rewriting history in this already, it's only been in the @Wrye-Bashers: Is everyone happy with my plans / method? I'd like to get this done tomorrow or Tuesday. Tuesday is more likely because rewriting history takes a fair amount of time and I have to do it several times. If everyone could squirrel away a copy of the repository in case I push to the wrong one online with screwed up changes, that would be good. |
Yes they need to routed on the tree as I mentioned - how exactly I dunno - I saw a procedure in SO but don't have the link
Probably cause they go with the svn config - I have them as remote branches: http://www.bild.me/bild.php?file=9062743tags.gif I still need to checkout local ones to see the stuff - not sure if you see them (that is the sharing of the svn config info part) Maybe the easiest thing is to reclone using my command line but with experimental and co added to I agree with what's left in/out Huge Diff is definitelly crlf and those tend not to disappear easily (http://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en) @lojack5 : mainly the cruft you mentioned (screenshots, experimental etc) - I believe the tags/branches can be got with my command line Most info is for SVN repos with standard layout whereas ours is not standard |
Oh, OK.
I'll give that a go tomorrow too, actually. |
@lojack5: For creating the meta repository, the following might work.
That will give you a repository with no branches or tags, and just the meta stuff, I think (untested). If you want, you could do the same with a dev-tools repo, just changing the EDIT: Actually, see below. You might have better luck running My attempt at I forgot that with
|
Rooting the git-svn branches to the tree - this particular answer : http://stackoverflow.com/a/4416172/281545 This was the link I referred to Also please when you do it consider adding a wiki page including the terminal ouput Another useful one: Importing SVN branches (and tags) on git-svn @WrinklyNinja :
In my questions in SO I have spread info also in the related issues here - of relevance also the wiki on fetching https://github.com/Wrye-Bashers/wrye_bash_refactoring/wiki/Working-with-git-svn---fetching-the-svn-commits - it features also my command line. Btw my I had also posted in the forums extensively but most of the relevant posts are in the resources above. Heck - ain't you happy we have a home to post this info ? The forums were such a pain to keep track of :D |
Sorry, I already did it. It's not something that we'll have to do again, so I'm not going to go back and fully document it. @lojack5, @Utumno: I have pushed my history-rewritten repository to here temporarily. Could both of you take a quick look at your branches in the repository, and make sure that everything is as you expect it, then post in here confirmation that it's OK. Once I've got confirmation from both of you, I'll:
I'm doing this so that we retain issue tracking, the wiki, etc. that are tied to this repository. At that point, no further history editing should be required, so the repository will be stable and "all" that will be left to do is:
|
@WrinklyNinja : Have no time to go through it now but will do ASAP
Still please if you somehow document the process it'd be nice (for instance the EDIT: on first look looks great - and light - what did you do with the branches/tags ? Agree on the wrye-bash name for the repo EDIT2: maybe now, that nothing is frozen, rebase squash Wrye-Code-Collection@96dccc9 ? :D Also - question - have I got time to push some last updates in my branch in wrye-bash-refactoring and have them in wrye-bash ? |
Comparing the size of the
I'll go over it when I'm done with everything then.
The branches are up there. Tags aren't yet.
Sure, I'll do that before I add the tags.
It would be easier if you didn't, I think, otherwise I'll have to |
Was editing as you posted - so reposting :in meta rename unicode_guidlines.txt to unicode_guidelines.txt I'd like to have a more careful look - yes repos are frozen now. Btw my remote branches show as
|
The meta repository is now done! Currently working through the |
Looks like the process went well, and I don't see anything missing that I didn't expect, so good there. If we're cleaning it up though, I'd say rename Another question though, I read through the branching model wiki and linked page more last night. I branced Everything else posted - sweet! I go to bed and @WrinklyNinja goes to town. Nice. Edit: Oh! Make sure we get a .gitattributes and .gitignore in there before we finalize it. And in the sister repos. |
Will do.
No, you might as well keep it.
Done for the sister repos. I'll do the wrye-bash repo in a bit. @Utumno: Are you happy for me to replace wrye-bash-refactoring? |
@WrinklyNinja : can't look thoroughly now but yes (my uncommitted stuff is few) .gitattributes and .gitignore are present in 304.4 don't add them to master. Better release ASAP - so we really move to git (with the users) Better rename The last commit in master is SVN 3177 ? We should record this (and related) info for the future generations, in the wiki article for the move. |
@Wrye-Bashers: This repository is now back open for business! I branched Still to do:
|
Well, I don't know if you've ever used GitHub's releases feature - if you haven't, you can basically associate a Markdown title and description and binaries with a repository tag, see BOSS's releases. I'd suggest we use that - if we then link to the Releases page, then we don't even really need a guide, IMHO. |
Sure, once I get the labeling/milestone stuff agree'd on I'll start porting those over. |
Well, all the tags have been transferred across. It's very early here now, so I'll work on my documentation tomorrow, then it'll be mostly back to BOSS for a few days, probably. |
Started working on the issues - there's a lot. I took care of Something I noticed, going back to our discussion on the proper labeling of issues: maybe we don't need Anyway, I'll work more on getting the issues over here tomorrow, going through by hand so that we don't get some invalid/out of date ones copied over. |
That makes sense to me. EDIT: My documentation is done. |
Didn't know about the release feature - sounds like the tool for the job - great! Has the tracker any depends and blocks semantics for the bugs ? So we could mark goals as dependent on a number of TODOs and impose an order - this would be nice EDIT: will go over the docs and try to create a git svn page for what I did gathering the info from the palaces I spread it |
Should we close this issue? OPs and Nexus descriptions need to be updated, but they're over on the |
I still have the rest of the trackers to move over here from sourceforge. And we should update the readme's and the few places in code/installer that reference sourceforge as well before closing. For the forum posts and stuff, sure issue opened on the |
OK, I searched for "sourceforge" in all the text files in
The auto-updater could be replaced by one that leverages the GitHub API, but I think that should be low priority, and I'm in favour of just disabling the current implementation in the meantime. |
Auto-updater: just opened #57 after reading this. Yes it should be axed, and I'll do that myself actually, because it actually causes problems and no one uses it anyway. |
@wrye-bash : we should assign this : anyone up to it ? |
I'm too busy sorting out BOSS/LOOT to do anything with Bash right now. |
@WrinklyNinja : ok thanks - just stay around @lojack5 could you ? |
bolt.py - this one needs to stay in (part of the backup settings code) |
@lojack5 : Such small things should be one off commits - If you add a Try keeping the commit message 80 chars (or 76? msysgit gui enforces the limit by providing a non re-sizable text box), then a newline then the body of the commit message. Notice how github displays commit messages |
Ok, did the branch, commit, merge (with FF). Seems to give the best options for not messing things up. Didn't bother pushing the local branch I used to do it though, no point really, unless you want me to. |
@lojack5 : you're my hero. Now should I/you open an issue for trackers from sourceforge ? That's what's left (OPs and the SVN message are done btw ?) |
Trackers - yes still needs to be done (I won't have time to hit them I think, trying to get the second post script in working order) OPs: #2 What do you mean by SVN message? |
Ok open an issue with a 1-2-3 and a range of items to be transferred and I'll give a hand
See Wrinkly's check list above:
|
Ah, then yes the SVN is already pointed to here. OPs aren't done (that's referenced in the Issue I linked to above, in the meta repo) |
OPs: https://github.com/wrye-bash/meta/issues/2 |
Have found no easy way of sharing the git svn config - so anyone can update master from the SVN and so anyone can dcommit from master to the svn
My efforts are described here: http://stackoverflow.com/questions/18006273/how-to-share-the-git-svn-configuration/18541945?noredirect=1#18541945
Related is the difficulties I have dcommit'ing:
http://stackoverflow.com/questions/21713729/dcommit-to-sourceforge-how-do-i-tweak-my-git-config-and-authors-file
Every little bit helps
The text was updated successfully, but these errors were encountered: