Re: MergeOnUpstream and team policy
2007/7/17, Gonéri Le Bouder <goneri@rulezlan.org>:
I use to do svn-buildpackage --svn-export to get a fresh exported
directory and then I work on it. When I want to commit I've just to go
back in the svn directory.
About the tarball on Alioth, I think it's the best solution to be able
to check out all the repository without to much pain and I don't
understand why we shouldn't do that.
I think one of the best features of our SVN structure is that, as Gonéri says, we can checkout the whole repository without much pain. I do it sometimes and it would really suck to have to spend too much time doing so. In any case, I guess one of the main implications of suggesting having the whole upstream tarball contents inside the SVN server is to avoid the usage of quilt or dpatch, and do changes directly on the sources. Right now, I remind all of you, we're using quilt as a reference patch manager (optionally dpatch, if it's too important), and keeping all of our changes inside the debian/ directory ( see
http://wiki.debian.org/Games/ToolsDiscuss ).
Also, I wonder if upgrades to newer upstream versions would be as smooth as now if we had the whole upstream source spread in the SVN server, and all our patches in a single .diff.gz one. I guess I got so comfortable using our current system that it would be quite a pain for me switching to the way I did all that stuff when I started.
This again opens the discussion on what is better, but it would be kind of a pity to restart again from scratch now that we found a way of handling the packages that makes most of us comfortable with. I'm not exactly sure of the implications of having everything stored in the SVN anyway... does it mean the games data too? that can be really big, if we need to include all the textures, sound files, mp3/ogg music and so, which can be quite useless to handle in SVN. At least I won't feel comfortable working in such a way now that I got used to our system.
In any case, the debate is open again, it seems, so I guess we're all invited to discuss it again, saying what the pros and cons of every option would be, and if it would be worth going through such a big transition now that we kinda found our way of doing things. What do you all think?
Miry
BTW: I don't personally use svn-buildpackage, and I don't plan on using it in the near future. In any case I gess we should try to make the rest of the Team as comfortable as possible, and giving the option of using it to those who want to use it, and to avoid its usage all of us that don't. I don't really understand about that MergeOnUpstream property, but if it's something that helps some people in the Team to work better, and it's not a huge effort for me, why not?
Reply to: