PyTFall > PyTFall: General information
<-- Archived -->
Xela:
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.
rudistoned:
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.
Xela:
--- Quote from: rudistoned on September 13, 2013, 05: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.
--- End quote ---
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.
rudistoned:
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.
Xela:
--- Quote from: rudistoned on September 13, 2013, 05: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.
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page
Go to full version