> I think you should keep 'master' in line with svn/trunk and do your personal > commit in a new 'vfr' branch.
Yes, that was the idea. However, I got a little screwed by someone renaming InsetNomencl.cpp to InsetNomenclature.cpp. ;).. Well, it's either me that didn't write the scripts well enough, or Git has a bit uncomfortabilities (?) with deleted files and/or Windows. That's why I was messing up when pushing the commits for the InsetCommandParams patches. Also, I have to sort of manually update the git to the svn server. I might improve on this, but it's less easy on windows. > We could also create a new common branch for > git only development. This branch would be used by people who would like to > switch to git entirely and would be merged into master (and svn/trunk) > periodically (everyday?). That's how Qt works I guess. They also immediately check that everything compiles before merging. However, what happens on merge conflicts if someone commits something to the git server and someone changed a same thing into the svn server ? Hmm.. if you can automatically merge.. why not everytime somebody commits something ? I feel that it's not suitable for us to wait for one day to see other one's commits. That does not help checking up on each other, helping each other out, and so forth. > Or we could do the opposite: create a read-only > branch "svn" and merge periodically commit from master where main > development would happen. > I like your first proposal more. On my pc, I have one checkout which is both under svn and git control. That works quite well if you know what you're doing. > Abdel. Vincent
