Duke4.net Forums: Request for Comment: Source Code Rearrangement - Duke4.net Forums

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Request for Comment: Source Code Rearrangement

User is offline   Hendricks266 

  • Weaponized Autism

  #31

No thanks.
1

User is offline   Striker 

  • Auramancer

#32

Any reason for this aside from SVN revision numbering and stubbornness? I've yet to see any logical reason to keep holding on to such a shitty system... makes it much harder than it needs to be to offer any kind of help to the project. SVN makes forking, synchronizing code, and merging an absolute chore. (A nightmare, even.)

Something like Git would allow someone to fork the main repository, make the necessary changes, and then make a pull request, where it can be looked at by a developer, complete with a breakdown of the changes, and then accepted/denied, and if merged, the commits from the fork are transferred, in the proper order in the main branch's commit history. If a particular fork is something big that takes a lot of time and effort, and the main repo is updated in the meantime with new commits... it doesn't take nearly as much effort to merge the new code with the fork. With SVN, someone working on their own fork would have to essentially start their repo from scratch with the updated code and patch their work in.

This post has been edited by Striker: 20 December 2016 - 10:07 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #33

We all use git-svn locally. It nullifies all of your arguments. There are zero push factors and zero pull factors to change our server setup.

EDIT: You edited your post.

View PostStriker, on 20 December 2016 - 09:47 PM, said:

Something like Git would allow someone to fork the main repository,

The concept of forking is agnostic to your chosen implementation of version control.

View PostStriker, on 20 December 2016 - 09:47 PM, said:

and then make a pull request,

Pull requests are not part of Git itself. They are a concept added by managed Git service providers such as GitHub and GitLab, which we will never use. If you're contributing, you're sending us patch files, mailing list style.

View PostStriker, on 20 December 2016 - 09:47 PM, said:

where it can be looked at by a developer, complete with a breakdown of the changes, and then accepted/denied, and if merged, the commits from the fork are transferred, in the proper order in the main branch's commit history.

Rebase to SVN HEAD and git format-patch your stuff. If you haven't split your work into separate commits of isolated semantic changes, you're already doing it wrong. We gatekeep our code very closely, there's no guarantee we would accept your changeset without modifications. See: PolymerNG.

View PostStriker, on 20 December 2016 - 09:47 PM, said:

If a particular fork is something big that takes a lot of time and effort, and the main repo is updated in the meantime with new commits...

git-svn.

View PostStriker, on 20 December 2016 - 09:47 PM, said:

it doesn't take nearly as much effort to merge the new code with the fork.

How does Git magically wave away the work of diffing? If you're splitting up your commits in a way that can be worked on independently of our server, I assume you're already using Git. git-svn rebase, git rebase master. Git doesn't solve merge conflicts any more than SVN does.

View PostStriker, on 20 December 2016 - 09:47 PM, said:

With SVN, someone working on their own fork would have to essentially start their repo from scratch with the updated code and patch their work in.

"Using SVN" doesn't even apply here because we won't accept huge monster single patches as they are, unless we split them ourselves.

This post has been edited by Hendricks266: 20 December 2016 - 10:20 PM

0

User is offline   Striker 

  • Auramancer

#34

git-svn isn't the same. That's just using the git tool as a client for a subversion repository (unless there's something I'm missing here). The workflow is entirely different when using a DVCS, which is far more intuitive when merging branches/forks, a godsend for open-source projects. Anyhow, I'm just going to wait until 75 comes back and speaks with you about the MP branch before I say anything else.

This post has been edited by Striker: 20 December 2016 - 10:33 PM

0

User is offline   TerminX 

  • el fundador

  #35

View PostStriker, on 20 December 2016 - 10:17 PM, said:

git-svn isn't the same. That's just using the git tool as a client for a subversion repository (unless there's something I'm missing here). The workflow is entirely different when using a DVCS, which is far more intuitive when merging branches/forks, a godsend for open-source projects. Anyhow, I'm just going to wait until 75 comes back and speaks with you about the MP branch before I say anything else.

There's a bit more to it than that. The interaction with the server basically involves cloning git commits into svn revisions, and vice versa, but you work locally as you would with any other git repo you have cloned. We aren't interested in changing over to some service provided by and run according to some corporate interest, worse yet anything run out of the SF bay area, for reasons that are obvious to some and less obvious to others.

We're looking into merging 75's work into svn soon anyway just so people see that something is happening with it. Been a long time coming, even if we're still far from the goal.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #36

It is done.

#!/bin/bash

svn mv polymer/synthesis.sh polymer/eduke32/platform/
svn mv polymer/eduke32/* ./
svn rm polymer

svn mv source/jaudiolib/third-party/common/include/* platform/Windows/include/
svn mv source/jaudiolib/third-party/Windows/lib/32/* platform/Windows/lib/32/
svn mv source/jaudiolib/third-party/Windows/lib/64/* platform/Windows/lib/64/
svn rm source/jaudiolib/third-party
svn mv source/jaudiolib source/audiolib

svn mv mact source/mact
mkdir "source/mact/src"
svn add source/mact/src
mkdir "source/mact/include"
svn add source/mact/include
svn mv source/mact/*.c source/mact/src/
svn mv source/mact/_scrplib.h source/mact/src/
svn mv source/mact/*.h source/mact/include/

svn mv source/testgame source/kenbuild

svn mv source/android/etcpak source/
mkdir "source/etcpak/src"
svn add source/etcpak/src
mkdir "source/etcpak/include"
svn add source/etcpak/include
svn mv source/etcpak/ProcessRGB.hpp source/etcpak/include/ProcessRGB.h
svn mv source/etcpak/*.cpp source/etcpak/src/
svn mv source/etcpak/*.hpp source/etcpak/src/

mkdir "source/tools"
svn add source/tools
svn mv build/src/util source/tools/src
svn mv build/src/misc/* source/tools/src/
svn rm build/src/misc
svn mv source/util/* source/tools/src/
svn rm source/util

svn mv build source/
svn mv source/rev.c source/build/src/
svn mv source/animvpx.c source/build/src/
svn mv source/animvpx.h source/build/include/

mkdir "source/duke3d"
mkdir "source/duke3d/src"
svn add source/duke3d
svn mv rsrc source/duke3d/
svn mv source/misc/* source/duke3d/rsrc/
svn rm source/misc
svn mv source/lunatic source/duke3d/src/
svn mv source/android/* source/duke3d/src/
svn rm source/android
svn mv source/*.c source/duke3d/src/
svn mv source/*.h source/duke3d/src/
svn mv source/*.m source/duke3d/src/
svn mv source/*.cpp source/duke3d/src/
svn mv source/*.txt source/duke3d/
svn mv source/duke3d/src/lunatic/defs.ilua source/duke3d/src/lunatic/_defs_game.lua
svn mv source/duke3d/src/lunatic/defs_m32.ilua source/duke3d/src/lunatic/_defs_editor.lua
svn mv source/duke3d/src/lunatic/dynsymlist source/duke3d/src/lunatic/dynsymlist_game.lds
svn mv source/duke3d/src/lunatic/dynsymlist_m32 source/duke3d/src/lunatic/dynsymlist_editor.lds
svn mv source/duke3d/src/lunatic/lunatic_m32.c source/duke3d/src/lunatic/lunatic_editor.c
svn mv source/duke3d/src/lunatic/lunatic_m32.h source/duke3d/src/lunatic/lunatic_editor.h

svn mv Makefile GNUmakefile
svn mv Makefile.deps source/duke3d/Dependencies.mak
svn mv source/build/Makefile.deps source/build/Dependencies.mak
svn mv source/sw/Makefile.deps source/sw/Dependencies.mak
svn mv Makefile.common Common.mak

svn mv *.vcxproj* platform/Windows/
svn mv *.sln platform/Windows/
svn mv Makefile.msvc platform/Windows/msvc.mak

svn rm package/sdk/samples/duke3d.def.sample
svn rm package/sdk/samples/enhance.con.sample
svn mv package/sdk/samples/weapons.con.sample package/sdk/samples/weapons.sample.con

svn mv source/tools/src/arttool.cc source/tools/src/arttool.cpp

for i in source/build/src source/tools/src source/kenbuild/src source/audiolib/src source/mact/src source/duke3d/src source/duke3d/src/lunatic source/sw/src; do
for j in $i/*.c; do
svn mv ${j} ${j}pp
done
done

svn mv source/build/src/lz4.cpp source/build/src/lz4.c
svn mv source/build/src/xxhash.cpp source/build/src/xxhash.c
svn mv source/build/src/jwzgles.cpp source/build/src/jwzgles.c

for i in source/build/src source/kenbuild/src source/duke3d/src source/sw/src; do
for j in $i/*.m; do
svn mv ${j} ${j}m
done
done

1

Share this topic:


  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options