Move to git (update links etc) about wrye-bash HOT 50 CLOSED

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:

• The git svn command line - this sidesteps to issue #7. I used :

  $ git svn clone --branches=Branches/Wrye\ Bash/* \
  --tags=Tags/Wrye\ Bash/* \
  --trunk=Programs/Wrye\ Bash/ --prefix=svn/ \ 
  --ignore-paths="^(?:Releases|Projects|Scripts|Games|)/|^Programs/\
  (?:Nif Scanner|Nif Viewer|Raziel23x's Oblivion Toolset|Shader Disasm|Shader Editor)/" \
  --authors-file=authors_with_emails.txt \
  svn://svn.code.sf.net/p/oblivionworks/code/ . >> 2013.07.28 2>&1
  

• Transferring the tags to git as git tags (many posts in SO)

• Rooting the branches to the git tree - the command above fetched them as unrooted (many posts in SO)

• Share the git svn info

• Be able to dcommit

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)

Lojack, on 12 Jan 2014 - 12:44 AM, said:
I guess my confusion: why even keep the SVN? If the master branch of your repo is always going to be mirrored to the SVN, why not ditch the SVN and everyone work directly on the master branch of the Github repo? Less confusion, you no longer have to do whatever svn-git stuff you need to do to sync it up with the SVN, etc.

cause users know the svn and it will take effort and precious time to instruct people, cause I am a bit anal and I would like to transfer all the bits of history to the git side but only those bits that matter (and this takes time and planning, and deeper knowledge than I have but it does pay off and it must be done), cause we ideally move the tracker also and change the scripts for second post etc etc, cause we need a sandbox where we can do silly things and learn to work together that is not a repository users will see - ...

especially 2
and 1

in general not much planning is the nature of Bash and its biggest issue

(edit : it is clear I hope that I do want to port the thing to git but not immediately - say in a couple of months when we all are comfortable and refactoring is under way and we have thought of the details. But not just yet - say the git repo is a sandbox.)

from wrye-bash.

Questions

1. Why do we need to share the git svn config?
2. Why do we need to dcommit to SVN at all?
3. Where is the documentation of your planning for the move from SVN to Git?
4. Is there a list anywhere of what you want to transfer and what you don't?
5. Why is the move going to take months?

Opinions:

1. A timeline of a couple of months for moving the repository is ridiculous. You're effectively placing the project in limbo for that period, because I for one am confused as heck over which repository I should be committing to / what the workflow is. Right now, I'm feeling a lot of uncertainty over developing Bash. I don't know what I should be doing where, or whether that will interfere with your own plans. That is bad, to the point where I'm seriously considering giving up contributing until the dust has settled. I don't want or need to deal with this headache.

2. The no doubt tiny minority of users who are checking code out from the SVN repo to run Bash are not drooling idiots. I'm sure that if we put a message up in the forum thread OPs and on the SourceForge thread that we've moved to GitHub, they'd catch on pretty quick.

   There are also a billion and one tutorials on the basics of how to use Git that we could link to, and if we're not happy with them, we could quickly write up a wiki page explaining it - I did one for BOSS. Speaking of which, most of the team had no previous experience with Git, and not once did I have to instruct anyone on the read-only aspects, which are the only bits that users will need to know.

   In light of that, "for the users" is not an adequate reason (IMHO) to hold on to two current repositories. By that I mean, I'm fine with the SVN staying online, but it should be made read-only, for historical reference, and no longer updated.

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.

from wrye-bash.

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:

1. Copy over any remaining branches that we are wanting to keep (are there any? dev-sharlikran and wrinklyninja's are all here I think), rebase them to the master branch here at the appropriate revision
2. Copy over any remaining tickets to here.
3. Turn the SVN read-only
4. Update the sourceforge page to redirect here
5. Update the readme/OP

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.

from wrye-bash.

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

from wrye-bash.

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.

from wrye-bash.

@Utumno: The wiki page you posted - am I right in thinking that you rebased wrinklyninja-bossv3-support on a commit in its own history, so that you could get rid of the binary and log file I added by accident, before merging into the b304.4 branch? Just trying to make sure I understand what the commands mean.

Also, I echo Lojack's sentiment.

from wrye-bash.

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 git log --grep=@<svn revision>. You can't use the SVN revision of the tags listed here, but you can walk back through them to find the latest revision before each tag to appear in the cloned repository.

I discovered this while trying to do a git-svn of the scripts folder only - it didn't like how the Tags folders also included other stuff, so I cloned without tags, then added them back in manually using git tag -a <tag name> -m <message> <sha>.

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 .gitignore, and changing the git filter-branch line to read git filter-branch --force --index-filter "git rm -r --cached --ignore-unmatched experimental" --prune-empty --tag-name-filter cat -- --all. Also I haven't force pushed my changes.

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:

• experimental
• screenshots - after looking at the SVN history, it looks like these were for Alt3n1ty, who isn't updating his guide anymore, so they don't need to be moved across.
• "Large" files committed by accident. I don't know yet what they are, but I'll have a look if there is anything.
• All the thread starter post and nexus description stuff. These will be going in a separate meta repository, which I'll make public shortly.

My reasoning for not rewriting out the scripts folder is given here.

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?

from wrye-bash.

@WrinklyNinja :The tags are here but as branches - not sure it's so easy as this though

filter-branch (if not a fresh clone) is what I thought of but never used it. If you do it then we must indeed be sure to commit everything I guess before the filtering.

@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

from wrye-bash.

@Utumno: Could you link me to a tag? I can't find them anywhere...

The reason I'm trying to use filter-branch rather than git-svn is because I feel that it's more flexible, and given that we already have everything here, we may as well use "native" git methods rather than trying to wrangle our way through the git-svn bridge.

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:

• experimental
• screenshots
• scripts/dist/Wrye Bash 304 - *
• NexusDescriptionPages
• Bug List thread Starter - *
• Forum thread starter - *
• Thread History.txt
• unicode_guidlines.txt

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 dev-sharlikran and 305 branches should be (deleting the existing ones), so I guess they'll need to be git-svn'd across, before any history rewriting happens. Again, I'll try to do it on my local repo before pushing anything.

from wrye-bash.

@WrinklyNinja:

• screenshots - Yes, for alt3rn1ty. Maybe this and the Forum Starter Thread - *, Bug List Starter Thread - * and Thread History.txt would be good candidates for a sister repo just to handle the forum posting stuff?
• NexusDiscriptionPages - Probably also go with the forum posting stuff repo I think.
• experimental - Good to just leave that on the SVN only.
• unicode_guidelines.txt - I'll make a wiki page for this, then that should be removed as well.
• scripts - As you've noticed, some stuff should stay, others shouldn't:
  • generate_second_post, generate_second_post.bat, second_pose_template.xsl - These are forum post stuff, however they're specific to SVN, so kill them.
  • test, convert_translator_format.py, installers.py, are scripts related to Bash, but special purpose tools. Possible candidates for a new 'dev-tools' type repo. Personal opinion is move them out so the the main repo is cleaner, and these are rarely used, but up to you either way.
  • All the rest of the stuff is directly related to building releases, so my gut instinct is leave them in, though my "I've starting cleaning and now I can't STOP!" wants to pull those out too into a 'dev-build' type repo. Probably best to leave them in though.

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)?

from wrye-bash.

@lojack5: I've already made a wiki page for the unicode guidelines. 😄

Thanks for the info on the stuff in scripts. I think I agree with everything there. As for creating a new repo for the forum stuff et al., I'm currently trying out stuff with git-svn and I'll post anything relevant.

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:

1. git svn init svn://svn.code.sf.net/p/oblivionworks/code/Branches/Wrye%20Bash/305
2. git svn fetch
3. git checkout git-svn
4. git checkout -b 305

I also did the same with his dev-sharlikran branch on the SVN, and when I diff the appropriate commit against the latest in this repository, it is identical. So I'm going to try pushing the new branches to this repository.

from wrye-bash.

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 unicode_guidelines.txt from the repo.

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.

from wrye-bash.

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 master that they came from in the SVN. I tried to do it with 305, but as you can see (I pushed the result), there's an enormous diff between the first (and only) commit in 305 and its parent in master, which is just deleting and adding the same files. I haven't figured out how to fix that yet...

from wrye-bash.

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.

from wrye-bash.

Oh, I hadn't thought of that... Anyway, I managed to fix the enormous diff issue in dev-sharlikran by doing an interactive rebase from two commits before the problem commit, and setting the problem commit to be fixup'd.

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:

1. Rewrite history to get rid of unwanted files.
2. Add tags to match the SVN tags.

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 305 and sharlikran-dev branches. Going forward, I'll be rewriting history for the whole repository.

@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.

from wrye-bash.

they are orphaned, which means when I push them, everything needs to be uploaded (nearly 30 MB).

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

Could you link me to a tag? I can't find them anywhere...

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 --ignore-paths

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

from wrye-bash.

Probably cause they go with the svn config - I have them as remote branches

Oh, OK.

Maybe the easiest thing is to reclone using my command line but with experimental and co added to

I'll give that a go tomorrow too, actually.

from wrye-bash.

@lojack5: For creating the meta repository, the following might work.

1. mkdir meta && cd meta
2. git svn init svn://svn.code.sf.net/p/oblivionworks/code/Programs/Wrye Bash
3. Edit .git/config to have the [svn-remote "svn"] section contain the line ignore-paths = ^(?:experimental|Mopy|screenshots|scripts|unicode_guidelines.txt)
4. git svn fetch.
5. git checkout git-svn
6. git checkout -b master (you may have to rename the current master then delete it)

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 ignore-paths line. One mistake I made with it is that backslashes don't escape periods, they just create an error message when you try to fetch, hence why unicode_guidelines.txt is unescaped.

EDIT: Actually, see below. You might have better luck running filter-branch, it's a fair bit faster too.

My attempt at git-svn'ing the repo without experimental and co didn't work, for some reason it exited at around r1400. I'll just do it rewriting history. That way I don't need to also worry about getting all the branches tied in at the right places all over again.

I forgot that with rm you can list several files & folders to delete, so my filter-branch command has become:

git filter-branch --force --index-filter "git rm -r --cached --ignore-unmatch experimental screenshots scripts/dist/* NexusDescriptionPages 'Bug List thread Starter - *' 'Forum thread starter - *' 'Thread History.txt' unicode_guidlines.txt scripts/generate_second_post scripts/generate_second_post.bat scripts/second_post_template.xsl scripts/test scripts/convert_translator_format.py scripts/installers.py" --prune-empty --tag-name-filter cat -- --all

from wrye-bash.

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 :

Where is the documentation of your planning for the move from SVN to Git?

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 ignore-paths could use some wildcards

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

from wrye-bash.

Also please when you do it consider adding a wiki page including the terminal ouput

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:

1. Force push my changes to this repository.
2. Delete the temporary repository I linked to above.
3. Rename this repository to wrye-bash.

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:

1. Add tags to this repository.
2. FIle issues here for those on the Sourceforge tracker.
3. Create meta and dev-tools repositories. I'm currently running the filter-branch commands for these.
4. Update links / put message on Sourceforge page.

filter-branch for meta:

git filter-branch --force --index-filter "git rm -r --cached --ignore-unmatch experimental Mopy scripts unicode_guidlines.txt" --prune-empty --tag-name-filter cat -- --all

filter-branch for dev-tools:

git filter-branch --force --index-filter "git rm -r --cached --ignore-unmatch experimental Mopy NexusDescriptionPages screenshots scripts/build scripts/dist scripts/Build* scripts/generate* scripts/mk* scripts/package_for_release.py scripts/second_post_template.xsl scripts/zipextimporter.py 'Bug List thread Starter - *' 'Forum thread starter - *' 'Thread History.txt' unicode_guidlines.txt" --prune-empty --tag-name-filter cat -- --all

from wrye-bash.

@WrinklyNinja : Have no time to go through it now but will do ASAP

feature-patcher-refactoring should be daidalos_patcher-refactoring - forgot to say before

Still please if you somehow document the process it'd be nice (for instance the authorsfile)

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 ?

from wrye-bash.

Comparing the size of the wrye-bash-refactoring and wrye-bash repositories, they're 173 MB and 59 MB respectively, so pruning history was a very good idea. 😀

Still please if you somehow document the process it'd be nice.

I'll go over it when I'm done with everything then.

what did you do with the branches/tags ?

The branches are up there. Tags aren't yet.

rebase squash Wrye-Code-Collection/wrye-bash@96dccc9 ?

Sure, I'll do that before I add the tags.

Also - question - have I got time to push some last updates in my branch in wrye-bash-refactoring and have them in wrye-bash ?

It would be easier if you didn't, I think, otherwise I'll have to filter-branch them. You could wait until the repos have been swapped, then rebase off the final product. Please consider the repos frozen until they have been swapped (which should be very soon after Lojack gives the OK).

from wrye-bash.

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

$ git branch -lr
  origin/Lojack
  origin/b304.4
  origin/dev-sharlikran
  origin/dev-sharlikran_AS_PUSHED
  origin/master
  origin/patcher_refactoring
  origin/utumno_MI_POC
  origin/utumno_basher_rip_out_constants
  origin/utumno_daidalos_based
  origin/utumno_daidalos_record_groups
  origin/utumno_daidalos_refacts_DRAFTS_UNTESTED
  origin/utumno_logs_refactor_on_MI_POC
  origin/utumno_logs_refactor_on_MI_POC_squashed
  origin/utumno_looking_into_helper_classes
  origin/utumno_refactoring_master
  origin/wrinklyninja-bossv3-support
  origin/wrinklyninja-fallout-support
  svn/291-fixes
  svn/294.2%20bugfixes
  svn/294.2-3329021
  svn/295-3329021
  svn/295-fixes
  svn/296-unicode
  svn/302-fixes
  svn/304_3%20BOSS%20v2
  svn/305
  svn/dev-sharlikran
  svn/tags/274
  svn/tags/276
  svn/tags/288
  svn/tags/289
  svn/tags/290
  svn/tags/291
  svn/tags/291.1
  svn/tags/292
  svn/tags/293
  svn/tags/294
  svn/tags/294.1
  svn/tags/294.1.test
  svn/tags/294.2
  svn/tags/295
  svn/tags/295.1
  svn/tags/295.2
  svn/tags/295.3
  svn/tags/295.4
  svn/tags/295.5
  svn/tags/296
  svn/tags/297
  svn/tags/297.1
  svn/tags/298
  svn/tags/299
  svn/tags/300
  svn/tags/301
  svn/tags/302
  svn/tags/302.1
  svn/tags/302a
  svn/tags/303
  svn/tags/304
  svn/tags/304.1
  svn/tags/304.2
  svn/tags/304.3
  svn/trunk

from wrye-bash.

The meta repository is now done!

Currently working through the dev-tools repo, it didn't shrink in size right, so I started again in case something went wrong.

from wrye-bash.

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.

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 Lojack to lojack-skyproc-support since that's what that one was really for.

Another question though, I read through the branching model wiki and linked page more last night. I branced lojack-vmad off of master, but if we're doing it exactly like the linked page I would branch off of develop. Should I just delete lojack-vmad until we've got the develop branch going? I was just going to wait til we have develop started then rebase to that once I realized.

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.

from wrye-bash.

If we're cleaning it up though, I'd say rename Lojack to lojack-skyproc-support since that's what that one was really for.

Will do.

Should I just delete lojack-vmad until we've got the develop branch going?

No, you might as well keep it.

Oh! Make sure we get a .gitattributes and .gitignore in there before we finalize it. And in the sister repos.

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?

from wrye-bash.

@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 lojack-vmad to dev and here we are with our development branch

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.

from wrye-bash.

@Wrye-Bashers: This repository is now back open for business! I branched develop off release-b304.4, rather than lojack-vmad, because it's how it should be done according to the proper workflow (but in reverse).

Still to do:

1. Add the rest of the tags. I've started this, but I'm only about 1/3 through so far.
2. I've got to finish documenting what I've been doing on the wiki.
3. Issues from Sourceforge's tracker need to be transferred over here - @lojack5, do you mind being in charge of that? I've got to sort out BOSS stuff, so probably won't be able to help out much with it.
4. The Sourceforge SVN needs to have a message redirecting users here added, and OPs / description pages need to be redirected too.
5. We should probably have a "how to use Git", if we had something similar for the SVN. I can't remember. I can adapt BOSS's guide if need be.

from wrye-bash.

Well done!

About 5 - we just need a guide for users to download releases (how we will manage this ?), using git in general there are plenty of resources

from wrye-bash.

About 5 - we just need a guide for users to download releases (how we will manage this ?), using git in general there are plenty of resources

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.

from wrye-bash.

Issues from Sourceforge's tracker need to be transferred over here - @lojack5, do you mind being in charge of that? I've got to sort out BOSS stuff, so probably won't be able to help out much with it.

Sure, once I get the labeling/milestone stuff agree'd on I'll start porting those over.

from wrye-bash.

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.

from wrye-bash.

Started working on the issues - there's a lot. I took care of Internal, Bug Graveyard, and started hitting into Enhancements.

Something I noticed, going back to our discussion on the proper labeling of issues: maybe we don't need accepted after all? If non-dev's can't tag an issue, then I suppose simply the act of having a label attached would indicate it's either accepted or rejected?

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.

from wrye-bash.

If non-dev's can't tag an issue, then I suppose simply the act of having a label attached would indicate it's either accepted or rejected?

That makes sense to me.

EDIT: My documentation is done.

from wrye-bash.

Didn't know about the release feature - sounds like the tool for the job - great!
Yes labeled == accepted - if accepted it does not really matter if it's reported by us. Only TODOs, git, goal will be exclusively by us.

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

from wrye-bash.

Should we close this issue? OPs and Nexus descriptions need to be updated, but they're over on the meta repository, so we might as well do that as an issue on it.

from wrye-bash.

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 meta repo.

from wrye-bash.

OK, I searched for "sourceforge" in all the text files in develop, and the files containing things that will need updating are:

• bash.py - Just a readme URL update needed.
• basher.py - I think this is the auto-updater.
• bweb.py - Sourceforge URL parsing. Doesn't seem to be used by anything else.
• bolt.py - A reference to a sourceforge16.png, which I can't find.

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.

from wrye-bash.

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.

from wrye-bash.

@wrye-bash : we should assign this : anyone up to it ?

from wrye-bash.

I'm too busy sorting out BOSS/LOOT to do anything with Bash right now.

from wrye-bash.

@WrinklyNinja : ok thanks - just stay around

@lojack5 could you ?

from wrye-bash.

bolt.py - this one needs to stay in (part of the backup settings code)
bash.py - only change left (in this repo, still need to handle the second post stuff). Should I just do it as a one-off commit to dev? Or just branch but merge with FF on?

from wrye-bash.

@lojack5 : Such small things should be one off commits - dev is the old svn trunk but hopefully more clean and sharp - so better to always create a local branch and play there a bit, squash oops commits together and merge to dev (if you have rebased on latest) Fast Forward

If you add a Fixes #18 in the commit body it will be linked to this issue in the github api

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

from wrye-bash.

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.

from wrye-bash.

@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 ?)

from wrye-bash.

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?

from wrye-bash.

@lojack5

Trackers - yes still needs to be done

Ok open an issue with a 1-2-3 and a range of items to be transferred and I'll give a hand

What do you mean by SVN message?

See Wrinkly's check list above:

The Sourceforge SVN needs to have a message redirecting users here added, and OPs / description pages need to be redirected too.

from wrye-bash.

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)

from wrye-bash.

OPs: https://github.com/wrye-bash/meta/issues/2
Tracker: #70

from wrye-bash.