Re: [Bf-committers] Let us switch to git, pretty please
paroneayea and I discussed moving to GIT at length and he brought up some issues which we'd need to resolve. - binaries may need to be masked out of SVN history so the initial checkout of lib/ isn't huge, (paroneayea said its possible with filter-branch when making the switch but its not trivial). More general issue is how well it performs once we have 500mb+ of binary changes in GIT too. - bf-extensions would also need to be moved, expect its possible but another complication, how to merge and keep history for both - not sure on this one. Another thing thats been discussed is having an SVN hook in our existing repo which keeps a GIT repo in sync. Currently the available GIT repos have some lag from trunk, With git matching trunk it would help us evaluate GIT without having to switch completely (interested in Nathan's opinion on this), it comes up from time to time as something we should do. As for moving to GIT (or any DVCS) - It would be good if people interested in evaluating this could make a local copy of the entire SVN repo to speed up tests and work out the necessary steps to move to see if we can even do this. Id like to look into this myself (hassling Marco for an account on the new SVN server now :) ). On Fri, May 27, 2011 at 5:02 AM, Mathias Panzenböck grosser.meister.mo...@gmx.net wrote: As long time bf-committers reader who has committed one or two tiny patches in the past I like to add: Pros for HG: More intuitive to use, especially things like revert. Nicely extensible using Python (e.g. generic keyring integration for repo passwords). TortoiseHg TortoiseGit and cross platform (Qt based). Pros for GIT: The SVN bridge seems to be much faster and transfers less data than HGs SVN bridge (last time I tried). Some people like this staging thing much. Never used it. It is said that a repo with many very different branches is smaller in GIT. github/gitourios bitbucket (but bitbucket is ok) Many things are possible in both, but the defaults differ. E.g. in HG you have to enable several extensions (that are included, just not enabled) to get things like paging+colors on the shell, rebase, squash (which isn't called like that in HG, I think) etc. But then in HG there is a built in webserver (`hg serve`) that supports pushes (if enabled)! It can also be hooked as CGI script with about two lines of Python code. But currently HG only supports Python 2.x. (I somehow like HG better.) -panzi On 05/27/2011 05:29 AM, Sergey I. Sharybin wrote: Hi, I'm not sure switching the whole repo to git is a nice idea. Last time i've checked this it was very painful to work with libs/ repo cloned with git -- simple `git status` used to work ages. Maybe this is because of plenty of binary files, not sure. And size of that local cloned repo was also incredible big -- several gigabutes, iirc. Git for codebase works really nice when you've got plenty of branches -- no pain with all this re-branching and so. Simple `git rebase` and here we go. There's also advantage for releases -- tagging happens much nicer with git. It'll be also more useful for pre-realse periods while codebase is frozen -- developers could still commit features to the development branch, but they wouldn't go to master. About clients i could say that git on linux works nice, msysgit works fine for windows. There's also TortoiseGIT. I haven't used it much, but it worked also nice. But i have to admit, that some firends of mine had some occasional troubles with it. P.S. as one more disadvantage, we'll be unable to have that rnumber in splash screen. It could be short commit SHA, but not sure it'll be useful. Tom M wrote: It was discussed a bit yesterday on irc as Jason was updating his sculpt branch to head that it would haven been much less pain with GIT potentially. Brecht and Ideasman and other core maintainers what are your views on moving to git or mercury? Ultimately the decision will be up to Ton of course, but would be good to get a straw poll on sentiment for it. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, Campbell I've been moving our work SVN repo to GIT at my previous job* and Nathan should have script which moves SVN repo into GIT repo with handling all branches and so. So i could make tests too. But i'd prefer to compare speed GIT vs. Mercurial. I haven't used mercurial myself, but there's information that GIT is much faster. I want to confirm this :) * It was script which reads every commit from SVN repo and makes the same commit in GIT repo -- this was made to avoid all that additional messages in commit logs created with git-svn.. Campbell Barton wrote: paroneayea and I discussed moving to GIT at length and he brought up some issues which we'd need to resolve. - binaries may need to be masked out of SVN history so the initial checkout of lib/ isn't huge, (paroneayea said its possible with filter-branch when making the switch but its not trivial). More general issue is how well it performs once we have 500mb+ of binary changes in GIT too. - bf-extensions would also need to be moved, expect its possible but another complication, how to merge and keep history for both - not sure on this one. Another thing thats been discussed is having an SVN hook in our existing repo which keeps a GIT repo in sync. Currently the available GIT repos have some lag from trunk, With git matching trunk it would help us evaluate GIT without having to switch completely (interested in Nathan's opinion on this), it comes up from time to time as something we should do. As for moving to GIT (or any DVCS) - It would be good if people interested in evaluating this could make a local copy of the entire SVN repo to speed up tests and work out the necessary steps to move to see if we can even do this. Id like to look into this myself (hassling Marco for an account on the new SVN server now :) ). On Fri, May 27, 2011 at 5:02 AM, Mathias Panzenböck grosser.meister.mo...@gmx.net wrote: As long time bf-committers reader who has committed one or two tiny patches in the past I like to add: Pros for HG: More intuitive to use, especially things like revert. Nicely extensible using Python (e.g. generic keyring integration for repo passwords). TortoiseHg TortoiseGit and cross platform (Qt based). Pros for GIT: The SVN bridge seems to be much faster and transfers less data than HGs SVN bridge (last time I tried). Some people like this staging thing much. Never used it. It is said that a repo with many very different branches is smaller in GIT. github/gitourios bitbucket (but bitbucket is ok) Many things are possible in both, but the defaults differ. E.g. in HG you have to enable several extensions (that are included, just not enabled) to get things like paging+colors on the shell, rebase, squash (which isn't called like that in HG, I think) etc. But then in HG there is a built in webserver (`hg serve`) that supports pushes (if enabled)! It can also be hooked as CGI script with about two lines of Python code. But currently HG only supports Python 2.x. (I somehow like HG better.) -panzi On 05/27/2011 05:29 AM, Sergey I. Sharybin wrote: Hi, I'm not sure switching the whole repo to git is a nice idea. Last time i've checked this it was very painful to work with libs/ repo cloned with git -- simple `git status` used to work ages. Maybe this is because of plenty of binary files, not sure. And size of that local cloned repo was also incredible big -- several gigabutes, iirc. Git for codebase works really nice when you've got plenty of branches -- no pain with all this re-branching and so. Simple `git rebase` and here we go. There's also advantage for releases -- tagging happens much nicer with git. It'll be also more useful for pre-realse periods while codebase is frozen -- developers could still commit features to the development branch, but they wouldn't go to master. About clients i could say that git on linux works nice, msysgit works fine for windows. There's also TortoiseGIT. I haven't used it much, but it worked also nice. But i have to admit, that some firends of mine had some occasional troubles with it. P.S. as one more disadvantage, we'll be unable to have that rnumberin splash screen. It could be short commit SHA, but not sure it'll be useful. Tom M wrote: It was discussed a bit yesterday on irc as Jason was updating his sculpt branch to head that it would haven been much less pain with GIT potentially. Brecht and Ideasman and other core maintainers what are your views on moving to git or mercury? Ultimately the decision will be up to Ton of course, but would be good to get a straw poll on sentiment for it. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org
Re: [Bf-committers] Let us switch to git, pretty please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't see the added value in moving svn.blender.org to DVCS per sé, but since we have had also ideas to use more stringent code review I'd propose the following: Developers (especially those we don't have commit right to current SVN) who wish can start working by cloning from the master branch of blender.git at gitorious.org/blenderprojects. Whenever they feel they have a feature ready in a feature branch in their personal clone they can prepare a patch and send it to codereview.appspot.com. Once accepted the patch can be applied to SVN trunk on svn.blender.org. If we stay with SVN, the same procedure still can apply for new features: create patch when you're done, send to codereview, wait for LGTM, commit. Whatever we choose, note that we'll very likely always have a select group of developers who have write access (push access or whatever the lingo for selected SCM is). Because of this I don't see it very useful to change the SCM _on svn.blender.org_. We can use gitorious.org mirror, developers can use svn+git, git-svn or any other way of doing Their Thing locally, while maintaining a commit history. Using Git or Hg or any other tool will not lessen the need for codereview, which is the real bottleneck here. So: gitorious.org/blenderprojects/blender.git for feature branches - people can make personal clones, create N feature branches, prepare patch and dance the review dance. In the end we still have to handle merges and resolve conflicts, this way it doesn't fall only to the designated person and we can have codereview more closely involved in the entire development process. Why blender.git? As Sergey already points out fullblender.git is *huge*, close to TWO gigabytes worth of clone. That is just not nice, and will need a lot of memory on pulls and pushes with changes in lib/* (or you'll have to be very patient on machines with not that much RAM, very patient - and hope the packing doesn't crash out). I've used Git on Windows for a long time now and I must say that the portable install of msys Git is good. The best tools IMO are gitk and git gui (picking single lines from unstaged changes to commit is pretty awesome), TortoiseGit somehow is very obscure to use. /Nathan On 27.5.2011 6:29, Sergey I. Sharybin wrote: Hi, I'm not sure switching the whole repo to git is a nice idea. Last time i've checked this it was very painful to work with libs/ repo cloned with git -- simple `git status` used to work ages. Maybe this is because of plenty of binary files, not sure. And size of that local cloned repo was also incredible big -- several gigabutes, iirc. Git for codebase works really nice when you've got plenty of branches -- no pain with all this re-branching and so. Simple `git rebase` and here we go. There's also advantage for releases -- tagging happens much nicer with git. It'll be also more useful for pre-realse periods while codebase is frozen -- developers could still commit features to the development branch, but they wouldn't go to master. About clients i could say that git on linux works nice, msysgit works fine for windows. There's also TortoiseGIT. I haven't used it much, but it worked also nice. But i have to admit, that some firends of mine had some occasional troubles with it. P.S. as one more disadvantage, we'll be unable to have that rnumber in splash screen. It could be short commit SHA, but not sure it'll be useful. Tom M wrote: It was discussed a bit yesterday on irc as Jason was updating his sculpt branch to head that it would haven been much less pain with GIT potentially. Brecht and Ideasman and other core maintainers what are your views on moving to git or mercury? Ultimately the decision will be up to Ton of course, but would be good to get a straw poll on sentiment for it. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers - -- Nathan Letwory Blender Foundation | Letwory Interactive http://www.blender.org | http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN30vBAAoJEKtfN7KsE0TtV9cH/i2FHyRYykCs6/zoytzTNzmA 7oHEurl8AIvzDBUOyV5Q2WV6Rr6k23c3ZNcFj9Lf1S9346Cgz3FPV0zIEtm+wBxe lRbRC7KJESfeKStKK+As/nelGCV5CeKrGE9Qufxr+cw+Gssy/ZXB3x7Cv9BWGqF2 TJepWwAsNBvpKal7qYs69wSKBNHQ2GX267dQ5ZiDwRZhOmZIdMimvJJygW0diBpc ip15Dedpo29qm/7WIQEhk/t+nI+0WbHE+Z80KOuIJo4C6ZbeZoHXr/hsOjVHEvx8 qaA+BNeDfYD6IHrfpZX/TurFBXq9RdSJqTNP8jiE8g6nPrsEt0fX2E4shOA450E= =g+C2 -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.5.2011 9:26, Campbell Barton wrote: paroneayea and I discussed moving to GIT at length and he brought up some issues which we'd need to resolve. - binaries may need to be masked out of SVN history so the initial checkout of lib/ isn't huge, (paroneayea said its possible with filter-branch when making the switch but its not trivial). More general issue is how well it performs once we have 500mb+ of binary changes in GIT too. http://gitorious.org/blenderprojects/blender | http://gitorious.org/blenderprojects/blender.git This is bf-blender trunk only. - bf-extensions would also need to be moved, expect its possible but another complication, how to merge and keep history for both - not sure on this one. http://gitorious.org/blenderprojects/extensions | http://gitorious.org/blenderprojects/extensions.git This is entire bf-extensions. Another thing thats been discussed is having an SVN hook in our existing repo which keeps a GIT repo in sync. Currently the available GIT repos have some lag from trunk, With git matching trunk it would help us evaluate GIT without having to switch completely (interested in Nathan's opinion on this), it comes up from time to time as something we should do. Running from my machine or directly with hook, whenever a new branch is created syncing fullblender takes a day or two. Having this hosted on a different machine than mine at home is always a good thing to look into. The barebone repo is 1.83GB right now. As for moving to GIT (or any DVCS) - It would be good if people interested in evaluating this could make a local copy of the entire SVN repo to speed up tests and work out the necessary steps to move to see if we can even do this. Id like to look into this myself (hassling Marco for an account on the new SVN server now :) ). As per my proposal, I wouldn't move svn.blender.org to DVCS, but keep it like that, and have people use blender.git who want to use Git (and with a local solution like svn+git, git-svn or any other bridge users even don't need a publicly maintained, official(-ish) mirror). /Nathan - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN303iAAoJEKtfN7KsE0TtQ3kIALD0z+XJ53MQDVzIbxcs8ENj O4zWrkxJgLAg3uIhiaL6qk0/JAAu/taSmkpRejbHoebt2z9L69Uibclzwiuk6bBm slwgYokJPdGma5XCRlxsKQqwvbEJR5D3gvMVpnWBzg6KYi8CTkSjtPikU8+XMjLx 17f+KwJJNOKynQTo2PWlsfX4G6PEdI7VPMB3CfLeZvHRaapfnhsrTNftLYybJPPU l3Ill8qJ63EK7LQ2ep/NKrIZ5PfwdXAuIIUGts9tGwwyHrPSXx6VO4aWuMGouTlK yMWziURbOGp98x3QvLVwpFFAQdXGIamDe14qdzlG39I5DtjyyLo9yfoO4SsgheU= =sdhQ -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, g.ula...@gmail.com (2011-05-27 at 0929.04 +0600): I'm not sure switching the whole repo to git is a nice idea. Last time i've checked this it was very painful to work with libs/ repo cloned with git -- simple `git status` used to work ages. Maybe this is because of plenty of binary files, not sure. And size of that local cloned repo was also incredible big -- several gigabutes, iirc. Yep, total is 3.5GB: .git/ ~1.5GB, blender/ 80MB, lib/ ~2GB. In some OSes, only blender/ and lib/tests/ are useful (120MB, plus whatever .git would be). Anyway, git status is fast here... could it be one of those cases that depends in the OS or filesystem? Git for codebase works really nice when you've got plenty of branches -- no pain with all this re-branching and so. Simple `git rebase` and here we go. There's also advantage for releases -- tagging happens much nicer with git. Speaking of different habits or workflow, some of the git tools work better when using git style. Take for example commit messages, first line is vital for some tools as it is used as summary in many places. Even commiting multiple topics as a single thing is disencouraged, and commiting to a tag is just impossible (in svn it works just because it is a branch, BTW). If you take other style, things work (or not), but you are going to expend too much time fixing the differences, and DVCS, everyone has to be own admin, so to speak. So the questions is if changing the software is worth if the methods stay the same. [...] P.S. as one more disadvantage, we'll be unable to have that rnumber in splash screen. It could be short commit SHA, but not sure it'll be useful. As useful as the svn rev number, show what was used to create the binary. It can make older-newer checks impossible if no access to the repo, but otherwise a minor problem. GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
Hi, nat...@letworyinteractive.com (2011-05-27 at 1008.18 +0300): Another thing thats been discussed is having an SVN hook in our existing repo which keeps a GIT repo in sync. Currently the available GIT repos have some lag from trunk, With git matching trunk it would help us evaluate GIT without having to switch completely (interested in Nathan's opinion on this), it comes up from time to time as something we should do. Running from my machine or directly with hook, whenever a new branch is created syncing fullblender takes a day or two. Having this hosted on a different machine than mine at home is always a good thing to look into. The barebone repo is 1.83GB right now. 1 day to push the git result or to import the branch op into git? The later here takes more or less the same than a (huge) commit, so it sounds suspicious (and git network ops are also rather efficient, so the first is also weird to hear...). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
From my experience i can clearly see that Blender project should be using GIT or Mercurial, and that switch is not only about eficiency and less pain, but also new development possibilities. Also, those who control the main code repository have the oportunity to demostrate that blender REALLY belongs to everyone. Cheers. 2011/5/27 GSR gsr@infernal-iceberg.com Hi, nat...@letworyinteractive.com (2011-05-27 at 1008.18 +0300): Another thing thats been discussed is having an SVN hook in our existing repo which keeps a GIT repo in sync. Currently the available GIT repos have some lag from trunk, With git matching trunk it would help us evaluate GIT without having to switch completely (interested in Nathan's opinion on this), it comes up from time to time as something we should do. Running from my machine or directly with hook, whenever a new branch is created syncing fullblender takes a day or two. Having this hosted on a different machine than mine at home is always a good thing to look into. The barebone repo is 1.83GB right now. 1 day to push the git result or to import the branch op into git? The later here takes more or less the same than a (huge) commit, so it sounds suspicious (and git network ops are also rather efficient, so the first is also weird to hear...). GSR ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
+100 \o/ I really know what you mean, I have this problem since the age of cvs.. so +1. On Thu, May 26, 2011 at 6:13 PM, Lukas Tönne lukas.toe...@googlemail.com wrote: Hello fellow coders, I have just had the mixed blessing of doing another git-svn branching from the 'particles-2010' svn branch i'm currently maintaining. Even though i already work with git locally to make use of its much nicer local staging and commit capabilities, the branching resulted in total merge conflict and countless hours of mind-numbing merge work. To cut to the chase, i reallly really want to work with git in the future, SVN is just horrible when it comes to maintaining several small projects in parallel. I tend to do a lot of branching with git locally, even for simple bugfixes, which is a really nice way to work. But it all goes haywire as soon as you try to work with remote repositories again or transfer stuff between branches, as long as there is no common base repository for git that defines unique sha1's for svn commits. For this reason i will completely stop working on the SVN branch in the future. Instead i will host public projects on gitorious.org and only do trunk commits on SVN. Last time this was discussed in the sunday meeting there was no real opposition to the idea of moving to a better vcs, only the question whether it would be git or mercury was left open. We can discuss this again of course, but if we want to make a move, we should do so before the actual coding for GSOC starts. Imo it would be a great help for all participants, especially with the elaborate branch structure that is planned. Cheers, Lukas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
It was discussed a bit yesterday on irc as Jason was updating his sculpt branch to head that it would haven been much less pain with GIT potentially. Brecht and Ideasman and other core maintainers what are your views on moving to git or mercury? Ultimately the decision will be up to Ton of course, but would be good to get a straw poll on sentiment for it. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
http://www.wikivs.com/wiki/Git_vs_Mercurial Other than not particularly liking SVN I've no personal preference, but it looks like Mercurial would be a better match for Blender -- both in terms of a Python orientation and Windows support. On Thu, May 26, 2011 at 5:25 PM, Tom M letter...@gmail.com wrote: It was discussed a bit yesterday on irc as Jason was updating his sculpt branch to head that it would haven been much less pain with GIT potentially. Brecht and Ideasman and other core maintainers what are your views on moving to git or mercury? Ultimately the decision will be up to Ton of course, but would be good to get a straw poll on sentiment for it. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- No essence. No permanence. No perfection. Only action. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
+1 for switching to git or Mercurial. I am also maintaining several git branches (across a few machines) locally and rebasing from SVN is a pain. - Original Message - http://www.wikivs.com/wiki/Git_vs_Mercurial Other than not particularly liking SVN I've no personal preference, but it looks like Mercurial would be a better match for Blender -- both in terms of a Python orientation and Windows support. I would prefer git, simply because that's what I already use - although the switch to Mercurial probably wouldn't be too painful. But I don't see why Mercurial's Python orientation is significant? Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Let us switch to git, pretty please
As long time bf-committers reader who has committed one or two tiny patches in the past I like to add: Pros for HG: More intuitive to use, especially things like revert. Nicely extensible using Python (e.g. generic keyring integration for repo passwords). TortoiseHg TortoiseGit and cross platform (Qt based). Pros for GIT: The SVN bridge seems to be much faster and transfers less data than HGs SVN bridge (last time I tried). Some people like this staging thing much. Never used it. It is said that a repo with many very different branches is smaller in GIT. github/gitourios bitbucket (but bitbucket is ok) Many things are possible in both, but the defaults differ. E.g. in HG you have to enable several extensions (that are included, just not enabled) to get things like paging+colors on the shell, rebase, squash (which isn't called like that in HG, I think) etc. But then in HG there is a built in webserver (`hg serve`) that supports pushes (if enabled)! It can also be hooked as CGI script with about two lines of Python code. But currently HG only supports Python 2.x. (I somehow like HG better.) -panzi On 05/27/2011 05:29 AM, Sergey I. Sharybin wrote: Hi, I'm not sure switching the whole repo to git is a nice idea. Last time i've checked this it was very painful to work with libs/ repo cloned with git -- simple `git status` used to work ages. Maybe this is because of plenty of binary files, not sure. And size of that local cloned repo was also incredible big -- several gigabutes, iirc. Git for codebase works really nice when you've got plenty of branches -- no pain with all this re-branching and so. Simple `git rebase` and here we go. There's also advantage for releases -- tagging happens much nicer with git. It'll be also more useful for pre-realse periods while codebase is frozen -- developers could still commit features to the development branch, but they wouldn't go to master. About clients i could say that git on linux works nice, msysgit works fine for windows. There's also TortoiseGIT. I haven't used it much, but it worked also nice. But i have to admit, that some firends of mine had some occasional troubles with it. P.S. as one more disadvantage, we'll be unable to have that rnumber in splash screen. It could be short commit SHA, but not sure it'll be useful. Tom M wrote: It was discussed a bit yesterday on irc as Jason was updating his sculpt branch to head that it would haven been much less pain with GIT potentially. Brecht and Ideasman and other core maintainers what are your views on moving to git or mercury? Ultimately the decision will be up to Ton of course, but would be good to get a straw poll on sentiment for it. LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
