On Sun, Sep 13, 2009 at 19:23, Christoph Egger
<debian@christoph-egger.org> wrote:
What I mean was, that the SVN checkout, as used in the games team, only
contains the debian dir. So you have to first «merge it with upstream
sources» in SVN-bp speak to make it useable with the stock commands and
the «normal» way of dealing with it is through the svn-buildpackage
command not the stock dpkg-bp and debuild ones.
I have no idea how DG team handles stuff, because I honestly didn't yet check out your sources, guys (I'm mostly lurking here to learn more about packaging and issues around it).
But...just ship a shell script that will fetch the latest upstream source? :-)
I know the svn-inject -o / merge-with-upstream thing is only one
possible setup for SVN but *please* don't start to include full sources
in SVN!
svn-inject -o / merge-with-upstream? Another thing to read about I guess :-)
I don't think SVN is bad. I just think that while git has definitely
more complexity there are some oddities in the svn-layout as well. And
the most troubling one IMHO is the fact you need to use special commands
for everything.
Not necessarily a bad thing. It quite certainly separates VCS management from doing stuff locally. If I want to temporarily copy a file, I won't accidentally be copying it in VCS as well. Same goes for deleting stuff locally; I won't accidentally commit the delete operation and thus break the thing for everyone unless they check out an earlier revision manually.
Just try to cp a svn tracked directory (not svn cp) and parse the error
messages while trying to add it to the tree. I doubt any newcomer to VCS
will succed there without help while git handles cp,rm,mv correctly even
if done with standard commands.
A newcomer would do well to RTFM, just like with git. :-)
No, really, just instruct the newcomer properly and don't rely on them to understand anything. I think it's better if they explicitly understand the difference when doing a VCS copy as opposed to regular filesystem copy. The earlier they understand what changes propagate, where they propagate and why, the better for them.
Both SVN and GIT have their uses. Personally, I find SVN quite sufficient for my needs, but my needs have so far always been software development and not software packaging. Finally, remember guys: you at least don't have to work with TF (Team Foundation). Always be thankful to the F.S.M. for his noodly appendages have rescued from such a horrible fate.
Just my (irrelevant) thoughts.