Author Topic: <-- Archived -->  (Read 27888 times)

0 Members and 2 Guests are viewing this topic.

Offline geoper

  • Newbie
  • *
  • Posts: 6
Re: -PyTFall- Communication and Repository Information
« Reply #30 on: September 09, 2013, 03:30:17 PM »
Hello, im new posting but I've been downloading the game a couple of times before. I tried to use the new repository, but basically we are trying to log in as you to sf, so, git is asking for a password or it just for me.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #31 on: September 09, 2013, 03:37:11 PM »
Hello, im new posting but I've been downloading the game a couple of times before. I tried to use the new repository, but basically we are trying to log in as you to sf, so, git is asking for a password or it just for me.

Nope, I got the wrong string, try this:

Code: [Select]
git clone git://git.code.sf.net/p/sbpytfall/code sbpytfall-code
PS: There is currently one known bug left where girls are not removed from girlsmeets after you hire them. I've fixed it and will upload the code a bit later.
« Last Edit: September 09, 2013, 03:38:42 PM by Xela »
Like what we're doing?

Offline ninjinto

  • Newbie
  • *
  • Posts: 11
Re: -PyTFall- Communication and Repository Information
« Reply #32 on: September 11, 2013, 08:56:31 AM »
Quote
singe repo instead of being split in two.
That's what I was thinking would solve the problem. Will check up on that then post more about it in a bit.

...Upon attempting: RenPy doesn't seem to recognize the project folder.

I did this:
git clone git://git.code.sf.net/p/sbpytfall/code sbpytfall-code

...and wound up with a folder called sbpytfall-code, which contained a folder called .git (hidden,) which contained a few more folders. The whole thing was about 15k so my guess is that it's not ready for downloading yet. Either that or the 1st post's clone command is no longer what we're supposed to use.
« Last Edit: September 11, 2013, 09:39:01 AM by ninjinto »

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4730
Re: -PyTFall- Communication and Repository Information
« Reply #33 on: September 11, 2013, 11:41:53 AM »
Jeez, maybe you guys should use db for now? I'm pretty sure it will work quick and flawlessly (just like always).

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #34 on: September 11, 2013, 12:59:03 PM »
Jeez, maybe you guys should use db for now? I'm pretty sure it will work quick and flawlessly (just like always).

Will not work as well for sharing code :(

I am getting Errors when downloading the repo as well... it seems to be going well but fails in the middle. I am trying GUI now.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4730
Re: -PyTFall- Communication and Repository Information
« Reply #35 on: September 11, 2013, 02:32:26 PM »
You could try at least to use git for the source code only if you want version control so badly, and share all content via db. It's 3 MB against ~700 MB, this way the probability of error on the part of the git will be much less.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #36 on: September 11, 2013, 02:53:25 PM »
You could try at least to use git for the source code only if you want version control so badly, and share all content via db. It's 3 MB against ~700 MB, this way the probability of error on the part of the git will be much less.

Yeap, that is one possibility, yet there is a but coming... I want git version to mimic my dev version. Otherwise I'll have to maintain three copies of code and that's complete crap. It's possible to use git for everything but char/rchar folders and that might be an acceptable solution.

BTW: I do not want/use version control while I am on my own or someone else is working on a closed system (Like Rudi's tag system). But if someone wants to contribute some code, it might not be a bad idea to figure out how to get git working.

What I've found out:

Code: [Select]
$> git config --global core.compression -1
$> git config --add core.compression -1

Entering these two commands should solve the EOF error that doesn't allow repo to be downloaded normally. I've tried it and am downloading the repo right now as a guest (without membership on SF/Project). I've killed my internet twice, ran a lot of different software and overloaded my line through torrents and yet git is still going strong... I'll let you know how it ends. I am currently using GUI so it doesn't report how many % is left.

PS: Not the right place to post it but Roman started on a decent engine for exploration/combat that could resemble Kamidori (haven't played it yet) when it's done. We could use something like that in the future. I am feeling much better as well so plan is to resume working on the game (Arena) tomorrow. I've been reading/listening to Python lectures in the meanwhile :)

Update:
Same Error... but the folder is increasing in size every time. It could be a temporary error, git seems to suck for large projects. I think I will get the whole 1.6 GB eventually...
« Last Edit: September 11, 2013, 03:13:07 PM by Xela »
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4730
Re: -PyTFall- Communication and Repository Information
« Reply #37 on: September 11, 2013, 03:51:08 PM »
git seems to suck for large projects
Maybe not only for large ones (§8 is so true  ::)). Just google for "git sucks" and enjoy even more angry reviews.

You could try bazaar or mercurial instead. The last one was created to effectively work with large repositories.
« Last Edit: September 11, 2013, 04:10:50 PM by DarkTl »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #38 on: September 11, 2013, 04:38:09 PM »
Maybe not only for large ones (§8 is so true  ::)). Just google for "git sucks" and enjoy even more angry reviews.

You could try bazaar or mercurial instead. The last one was created to effectively work with large repositories.

LoL

Mercurial gets extra points for Python... but they are very similar in their core... if git'll keep crapping out on us, I'll try mercurial next.
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #39 on: September 12, 2013, 11:43:57 AM »
Done with the git!

Fecking peace of [email protected] downloaded 8.5 Gb of data for the project that's currently 1.6 GB and still failed to build sh!t. At this point I don't even care why there are errors or why it's not working. I am trying out Mercurial now.
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #40 on: September 13, 2013, 03:33:27 AM »
Mercurial seems to be a piece of sh!t as well or maybe I am just missing something... basically every time you push and push fails, you have to start all over again, it doesn't keep files that were successful on the server. I'll keep trying, if it doesn't work out, I'll add char/rchar folders to ignore lists and up those to Mega, in that case we could have used git just as well.
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: -PyTFall- Communication and Repository Information
« Reply #41 on: September 13, 2013, 04:01:08 AM »
My 2 cents:

I love mercurial, especially because TortoiseHg offers a very nice GUI for it. I have no experience how it works over networks, but it should perform reasonably well, given the fact that for example the Mozilla project uses it.

Both mercurial and git are suited for large projects (=many contributors, many files). Git is used to develop the linux kernel after all. However, both mercurial and git are distributed version control systems, so both, by definition, suck for repositories containing many large binary files, especially if those binary files change frequently. Storing many large binary files and modify them every now and then is exactly what we will be doing with the girl images if we store their tags as XMP metadata.
What we should do, IMHO, is keep the source code in mercurial (or git) and move the ressources somewhere else. Options:
a) SVN. Subversion can handle large binary files with frequent changes somewhat decently, but we will still see a significant increase in repository size over time. However, due to its centralized nature, the growing repository will not bother developers, only the server hosting the repository.
b) Dropbox, Mega, ...; No version control, therefore no repository size increase, but also no incremental updates.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #42 on: September 13, 2013, 04:10:42 AM »
My 2 cents:

I love mercurial, especially because TortoiseHg offers a very nice GUI for it. I have no experience how it works over networks, but it should perform reasonably well, given the fact that for example the Mozilla project uses it.

Both mercurial and git are suited for large projects (=many contributors, many files). Git is used to develop the linux kernel after all. However, both mercurial and git are distributed version control systems, so both, by definition, suck for repositories containing many large binary files, especially if those binary files change frequently. Storing many large binary files and modify them every now and then is exactly what we will be doing with the girl images if we store their tags as XMP metadata.
What we should do, IMHO, is keep the source code in mercurial (or git) and move the ressources somewhere else. Options:
a) SVN. Subversion can handle large binary files with frequent changes somewhat decently, but we will still see a significant increase in repository size over time. However, due to its centralized nature, the growing repository will not bother developers, only the server hosting the repository.
b) Dropbox, Mega, ...; No version control, therefore no repository size increase, but also no incremental updates.

Thanks for the advice. I really like TortoiseHg as well :)

I think SF Mercurial + Mega will work best, I'll try to get it done today.
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: -PyTFall- Communication and Repository Information
« Reply #43 on: September 13, 2013, 04:21:55 AM »
A note of caution when using mercurial:
History in mercurial is designed to be permanent. Once you commit something, it is there to stay, especially if you push it to the main repository other developers pull from. It is possible to edit history, but unlike in git this is difficult and messy in mercurial.
Permanent history is not necessarily a bad thing, but it means one should be a bit more cautious when commiting changes. One exception: you can always undo the last commit in your repository using rollback, unless you have already pushed it to the main repository.


Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Communication and Repository Information
« Reply #44 on: September 13, 2013, 04:26:04 AM »
A note of caution when using mercurial:
History in mercurial is designed to be permanent. Once you commit something, it is there to stay, especially if you push it to the main repository other developers pull from. It is possible to edit history, but unlike in git this is difficult and messy in mercurial.
Permanent history is not necessarily a bad thing, but it means one should be a bit more cautious when commiting changes. One exception: you can always undo the last commit in your repository using rollback, unless you have already pushed it to the main repository.

Hmm, I don't think it's a bad thing either, I mean you can still revert to previous versions. Nice tip on the rollback, I didn't know that.

Edit:
I still don't understand why they cannot copy files on per file basis, seems kinda stupid... but I am sure they had reasons. I've uploaded rchars to Mega, uploading chars to Mega right now and game files to SF.
« Last Edit: September 13, 2013, 04:31:41 AM by Xela »
Like what we're doing?