On 02/24/2017 08:21 PM, Ivo Raisr wrote: > Dear Valgrind community, > > We are pleased to announce an imminent migration of Valgrind sources > from existing Subversion SCM to modern git SCM, as discussed during > our FOSDEM 2017 Valgrind devroom.
Very nice, thank you. > > What is going on now? > ~~~~~~~~~~~~~~~~~ > The migration has just started. We are now in beta testing stage. > We still use the official SVN Valgrind repository for our work until > the final migration step. If you have some patches ready now, send > them for review. > You can contribute to the migration process - read below. > > What will be migrated: > ~~~~~~~~~~~~~~~~~ > Valgrind and VEX sources. Precisely sources available today under > svn://svn.valgrind.org/valgrind and svn://svn.valgrind.org/vex, including > all production release branches and tags. Valgrind and VEX repos will > be merged into one, so no more SVN externals. > > Where I will find the new repo: > ~~~~~~~~~~~~~~~~~~~~~~~ > At sourceware.org. Precisely at: > git://sourceware.org/git/valgrind.git/ > http://sourceware.org/git/valgrind.git/ > Right now a snapshot of SVN sources as of 2017-02-21 is available for > you to test. > > How the test migration was performed: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > See recipes at https://github.com/ivosh/valgrind-git-migration > > What is the plan for the migration to go forward: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1. Test migration has been performed and initial tests were successful. > 2. The test repo is now available to test and play for others with - see below > for details. > 3. Prepare www (website) and nightly build script changes and have > them reviewed. > 4. Proceed once 2+3 are successfully done. > 5. Announce the final migration. > 6. Completely eradicate contents in the GIT repository so the migration > can start from scratch. > 7. Switch SVN valgrind+vex repo readonly. > 8. Perform the final migration to sourceware.org. > 9. Enable email notifications from new git repo. > 10. Push www and nightly script changes to the new repo. > > What will not be migrated: > ~~~~~~~~~~~~~~~~~~~~ > - Valgrind www (website) repo. Not now, but later. > - Non production release branches and tags from old SVN Valgrind+VEX repos. > If you need to preserve some other branches or tags, let us know: > https://sourceware.org/git/?p=valgrind.git;a=heads > https://sourceware.org/git/?p=valgrind.git;a=tags > > I have a write access to existing SVN repo. What shall I do for the new one? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Please contact Julian Seward. He will point you to specific instructions. > > What will be my simple workflow in new git SCM? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Not much will be changed from the way we worked in SVN. > We still prepare patches, send them for review, have someone > with write access to push them. A minimalistic workflow would be: > > git clone git://sourceware.org/git/valgrind.git/ valgrind > edit/compile > git status/add/show > git pull origin/master For a pull like approach I would suggest to either a: do not this step (Linux style git handling) b: use git pull --rebase (flat history style) > build + test > git commit > [git push - if you have write access] If we give write accesses, then I suggest to use the --rebase variant. Not sure what git server is running, but git-o-lite for example allows to reject non-fast-forward merges, so that we do not fill the history with single patch merge commits. Merge commits can be very useful though, if the merge commit contains a description of a multititude of patches. > > There are a lot of good tutorials on simple git workflows, so please > have a look. If you are using something more complicated, please > share with us and ideally send us a write up. > > I would like to help with the migration. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Yes, please! Send us your positive and negative feedback. > For example: > - It worked for me! > - This and that did not work for me... > - How do I do such and such thing now? > > The test repository is there for you to play with. The contents > will be deleted before the final migration so no reason to worry about > potential mistakes. It is also quite likely that the contents will be > regenerated during the beta testing, to fix any problems found. > > We also need a help documenting possible workflows. Especially when > preparing a release - we need to test and document how to work with branches > and releases. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
