dunkaist wrote:Here are questions and issues to be addressed if moving to git.
- Unlike svn revision numbers, git hashes are not increasing numbers.
- This creates navigation difficulties for pages like history of builds.
- It becomes harder to binary search prebuilt images.
- It is harder to tell if the commit c0ffee is newer than the commit deadbeef.
- Git hashes are longer than svn revision numbers, UI fixes may be needed (at least on the blue screen).
- Autobuild scripts operate on svn revision numbers, and are to be updated to work with git hashes. Some scripts are written in perl.
- There are existing references to svn.
- In source and documentation files.
- In board posts.
- There is sf18.13 that returns svn revision number.
- And maybe programs using it, who knows.
- Current setup uses svn keywords and properties, e.g. Revision and eol-style. How to provide this functionality with git?
- WebSVN should be replaced.
- Existing svn tags and branches should somehow be moved to git.
- We can continue maintaining revision number (starting from the latest SVN commit) - one file and it's done.
- Solved if we use revision number.
- Solved if we use revision number.
- We always can append revision number to a commit message using git hook.
- Solved if we use revision number.
- I'll take care of the scripts.
- The more we wait the more references we have.
- With revision system we can leave it, just replace SVN by Rev. in places that need it.
- The same for board posts.
- Not a problem if we maintain revision number.
- Havent checked how SVN does it, but I think we can create symple script that does this instead of svn.
- As mentioned, there are similar systems for git, but IDK how difficult it will be for server maintainers.
- I'll take care of it, it's big but essentially simple work TMK.
Do we have any other problems with switching to git? If no, I'm ready to start it incrementally.