Re: [crossfire] SVN history issues
Klaus, thanks for the offer. Though I guess my original question was less about finding the original materials, and more about possibly "fixing" the history in-place, so that it's cleaner moving forward. --Nathan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN history issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello everybody, I've got some old arch.tar files from 2008 (crossfire-1.11), 2009 (crossfire-1.12), 2011 (crossfire-1.60), 2012 (crossfire-1.70) and maybe some data from 2017. Interested? Klaus Am 18.02.2021 um 07:20 schrieb Mark Wedel: > On 2/17/21 6:56 PM, Nathaniel Kipps wrote: >> On Tue, Feb 9, 2021 at 12:33 AM Mark Wedel wrote: >> >>> The images may be recoverable - this presumes that the initial >>> import to CVS didn't result in corruption, but rather the CVS -> SVN >>> conversion resulted in corruption. If the image in questions are in >>> the actual crossfire-arch distribution, versions exist on >>> sourceforge for download that predate the SVN conversion, so it may >>> be possible to download one of those arch distributions and just >>> copy over the pre-corrupted images into the current arch tree and >>> recommit. >> >> I'm not terribly worried about the images being permanently lost. What >> I'm more interested in is if it's possible to "fix" the history so >> that it's easier to browse in the future. And, if so, is it easier to >> fix it while we're using SVN, or once we move to Git? > > Unless someone has a backup of the CVS repo, I think the CVS > commits/rename information is now lost (I looked, and don't have a CVS > backup). > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire - -- "Once we know the number one, we believe that we know the number two, because one plus one equals two. We forget that first we must know the meaning of plus." Alpha 60 __ Deutsches Forschungszentrum für Künstliche Intelligenz GmbH (DFKI GmbH) Klaus Elsbernd; System Administrator | klaus.elsbe...@dfki.de Trippstadter Straße 122 | elsbe...@dfki.uni-kl.de 67657 Kaiserslautern; Germany | Fernruf:0631/205755860 Fernbild:-5820 Geschäftsführung: Prof. Dr. Antonio Krüger (Vorsitzender) Vorsitzender des AR: Dr. Gabriël Clemens | Amtsgericht Kaiserslautern, HRB 2313 -BEGIN PGP SIGNATURE- Version: Encryption Desktop 10.4.2 (Build 10384) Charset: utf-8 wsBVAwUBYEUWk9ubSYkPCbCyAQqgdQgApzDS4/HWmsj56LpX6yTdFBjCn2v7D3me f/nosWrOX6Ae6aF3ULsa3HemXImduyxitS3x+euEPkcX5h+s7qg3wRH2pn8w/yHI 1xL2IH+50gh62Ml0/RBDbMOP66as2tgKbmxWE/WoLVSc0kFRgvEIThEXezh+k/6t hfPl6V3C/6O+1FAolV65e0vxz8djUHNoGknyJl9Y9qFIcNblc7hINXcU8DDlCHnu p/I8wUDyNUSCPBA4z2e5aW/bLldnmbRB8eIZWhynaUBIJEexGOIdxK5Ve8PfyLuG KQxb9oYgIZG43orpui92UAOrQBbhKf7ut/Gp3P6Qz4n9eglvH9pckg== =Oano -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN history issues
On 2/17/21 6:56 PM, Nathaniel Kipps wrote: On Tue, Feb 9, 2021 at 12:33 AM Mark Wedel wrote: The images may be recoverable - this presumes that the initial import to CVS didn't result in corruption, but rather the CVS -> SVN conversion resulted in corruption. If the image in questions are in the actual crossfire-arch distribution, versions exist on sourceforge for download that predate the SVN conversion, so it may be possible to download one of those arch distributions and just copy over the pre-corrupted images into the current arch tree and recommit. I'm not terribly worried about the images being permanently lost. What I'm more interested in is if it's possible to "fix" the history so that it's easier to browse in the future. And, if so, is it easier to fix it while we're using SVN, or once we move to Git? Unless someone has a backup of the CVS repo, I think the CVS commits/rename information is now lost (I looked, and don't have a CVS backup). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN history issues
On Tue, Feb 9, 2021 at 12:33 AM Mark Wedel wrote: > The images may be recoverable - this presumes that the initial import to > CVS didn't result in corruption, but rather the CVS -> SVN conversion > resulted in corruption. If the image in questions are in the actual > crossfire-arch distribution, versions exist on sourceforge for download that > predate the SVN conversion, so it may be possible to download one of those > arch distributions and just copy over the pre-corrupted images into the > current arch tree and recommit. I'm not terribly worried about the images being permanently lost. What I'm more interested in is if it's possible to "fix" the history so that it's easier to browse in the future. And, if so, is it easier to fix it while we're using SVN, or once we move to Git? --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN history issues
On 2/5/21 8:52 PM, Nathaniel Kipps wrote: Recently I was rooting through SVN history, trying to trace some old facesets and PNGs, when I found a few anomalies. Maybe someone with more experience than me is able to determine: * Can these be fixed retroactively? * If so, is it easier to fix them in SVN or Git? You assessment below on the causes is likely correct (going back to CVS repo). I think at the time of the CVS->SVN conversion, the CVS repos were still active, with the idea being that if anyone wanted to see the earlier history, they could still go back to the CVS repo. But it looks like the CVS repos disappeared - going by how many years since, probably not unreasonable. It is also worth mentioning that the CVS repo on sourceforge was not the first repo. I sort of recall a CVS repo hosted elsewhere, and before that, it was an RCS repo on the maintainers (my) machine. I suspect the commit messages may be completely lost - I checked my local system to see if maybe I had a backup of the CVS stuff repo itself, but I couldn't find one. The images may be recoverable - this presumes that the initial import to CVS didn't result in corruption, but rather the CVS -> SVN conversion resulted in corruption. If the image in questions are in the actual crossfire-arch distribution, versions exist on sourceforge for download that predate the SVN conversion, so it may be possible to download one of those arch distributions and just copy over the pre-corrupted images into the current arch tree and recommit. The first issue is that at least one time in the past, a number of files were moved or renamed, but instead of tracking the change, it was treated as a large number of deletions and new files. The instance I found was r1487, in which mwedel renamed most or all of the face images. This was presumably done under CVS, and the broken history was passed into SVN. This is certainly not a catastrophic problem, as it's not too hard to continue tracing the history of the file, but it's certainly annoying. The second (and more severe) issue is that a lot of old PNGs have become corrupted. An example would again be r1487, where it appears that all the old images are broken, and all the new ones are fine. Thanks to some folks in IRC, we determined that the *older* images have been corrupted by insertion of extra CR symbols, as though something was trying to convert the file from LF to CR/LF. My best guess is that the PNGs were tagged wrong in CVS, then during the CVS to SVN conversion, the accidental CR/LF conversion was done on the PNGs. Supporting this theory is r13991, in which anmaster comments "Fix incorrect svn properties ... that could in worst case result in corruption." Anyone have any thoughts on whether fixing these is possible, and if so, how much effort might it require? --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN history issues
Recently I was rooting through SVN history, trying to trace some old facesets and PNGs, when I found a few anomalies. Maybe someone with more experience than me is able to determine: * Can these be fixed retroactively? * If so, is it easier to fix them in SVN or Git? The first issue is that at least one time in the past, a number of files were moved or renamed, but instead of tracking the change, it was treated as a large number of deletions and new files. The instance I found was r1487, in which mwedel renamed most or all of the face images. This was presumably done under CVS, and the broken history was passed into SVN. This is certainly not a catastrophic problem, as it's not too hard to continue tracing the history of the file, but it's certainly annoying. The second (and more severe) issue is that a lot of old PNGs have become corrupted. An example would again be r1487, where it appears that all the old images are broken, and all the new ones are fine. Thanks to some folks in IRC, we determined that the *older* images have been corrupted by insertion of extra CR symbols, as though something was trying to convert the file from LF to CR/LF. My best guess is that the PNGs were tagged wrong in CVS, then during the CVS to SVN conversion, the accidental CR/LF conversion was done on the PNGs. Supporting this theory is r13991, in which anmaster comments "Fix incorrect svn properties ... that could in worst case result in corruption." Anyone have any thoughts on whether fixing these is possible, and if so, how much effort might it require? --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN write access to Kevin Zheng
Hello. > Kevin Zheng has contributed a number of patches to maps that have been > added and accepted to the Crossfire code base. > > He now has the necessary access and permissions to directly contribute > code changes. > > Kevin - thank you for all your work and contributions. Welcome aboard > the project! Thanks Rick for the "administrative" handling, and welcome on the team Kevin. :) Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN commit access
> I have recently been getting quite a few patches into svn for the server > source (look in trunk ChangeLog for "Arvid Norlander"), and have been > considering trying to become a developer, gros, Ryo and Ragnor (iirc) have > all indicated this may be a good idea on IRC. So here is the request: > commit access to the server source in svn, mostly in order to: 1) Clean up > source, fix messy/bad/old source > 2) Fix bugs (both security related and otherwise), memory leaks, valgrind > errors. 2) Writing unit tests for server (has been requested by Ryo on IRC) > > I may have occasional bug fix for the gtk based clients too but my main > interest is in the server source. Support for SVN access - just don't make big breaking changes without discussion first :) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN commit access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I have recently been getting quite a few patches into svn for the server source (look in trunk ChangeLog for "Arvid Norlander"), and have been considering trying to become a developer, gros, Ryo and Ragnor (iirc) have all indicated this may be a good idea on IRC. So here is the request: commit access to the server source in svn, mostly in order to: 1) Clean up source, fix messy/bad/old source 2) Fix bugs (both security related and otherwise), memory leaks, valgrind errors. 2) Writing unit tests for server (has been requested by Ryo on IRC) I may have occasional bug fix for the gtk based clients too but my main interest is in the server source. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkguBpsACgkQWmK6ng/aMNnaWQCdF5kSXrsWKhCdZ5XVLE6/HiiT JpkAnjPxdTPmGMp7R8Vw153Zs9569ko0 =ANjo -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN password reset notice from SourceForge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Announcement from SF website.. ( 2008-03-06 14:23:47 - SourceForge.net Web Site ) In support of improved security, all SourceForge.net user passwords have been expired and must be changed upon next login. CVS, Subversion and Shell users will need to login to the site to change their password before they will be able to access these services. http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#1181767103 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0NPshHyvgBp+vH4RAuOyAJ9U3QBKv1rYUhnuT0SN4uKeIMvOxgCfcgBY wVwnSCzbXpumzE2iqqdJ5uI= =aK1G -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN Checkin - updated python based guild maps (templates)
A user error on my part has resulted in the SVN commit for the python based guild maps templates being spread across multiple commits in Trunk. Revision 5526 contains /templates/guild/mainfloor Revision 5528 contains the updated README.txt Revision 5529 contains /templates/guild/guild_HQ and /templates/guild/secondfloor I apologize for the confusion and inconvenience. I'm working to make sure the commit to branch/1.x is "cleaner" Best regards, signature.asc Description: OpenPGP digital signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Alex Schultz wrote: > Agreed with the reason below, but the problem with that, is that > version.h shouldn't append "-r" unless it has a SVN_REV, and easier to > check in defines if SVN_REV is defined at all, instead of checking if > it's "" or not. Because of that, it seems like a better idea to me to > leave the SVN_REV check as I suggested, not include svnversion.h in SVN, > and make it just make an empty file if it doesn't have a revision. That would be fine. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Mark Wedel wrote: > It should actually get that version number from autoconf, like it does > now. > Then as part of that, for official releases, the -dev tag can be removed from > configure.ac > I didn't know that autoconf currently stored that. That makes sense to me. > In addition, if the makefile doesn't find a .svn directory, or does not > find > svnversion, it should create a svnversion.h file with an empty SVN_REV, eg: > > #define SVN_REV "" > > To the best of my knowledge, there isn't really any way to include a file > if > it exists, don't include it if it doesn't. So it is just a lot simpler to > always include it. > Agreed with the reason below, but the problem with that, is that version.h shouldn't append "-r" unless it has a SVN_REV, and easier to check in defines if SVN_REV is defined at all, instead of checking if it's "" or not. Because of that, it seems like a better idea to me to leave the SVN_REV check as I suggested, not include svnversion.h in SVN, and make it just make an empty file if it doesn't have a revision. > You really don't want the svnversion.h file to be any part of SVN, because > otherwise people will accidentally check it in and now have a version number > that isn't correct. > Agreed, though see above. >> The >> build process running svnversion because not all revisions require >> ./configure to be re-run. Also, it will only write svnversion.h if a >> check shows that it was checked out from official crossfire svn, this is >> to ensure all revision numbers correspond to the same repository. >> > > I think checking for official repository checkout is probably overkill and > isn't needed. After all, if a developer really wants to have a bogus SVN_REV > number, there are a lot easier ways to do it. > Well, I was more thinking of server admins accidentally doing that. Of course, if they set up their own repositories, they should be competent enough to either disable sending the revision or to make the base version unique. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Christian Hujer wrote: > On Friday 13 October 2006 19:15 Brendan Lally wrote: >> Likewise, although the clients need only open a connection to the >> metaserver to recieve the server list, having the official clients >> send their revision numbers by default would give some indication as >> to which versions of the clients are in use. (assuming the metaserver >> were suitably modified to read that information from the socket). > Oh that would make it easy for a bogus server to abuse or exploit known > client > bugs to hack client machines. Well, right now, the client does support some basic information to the server when it connections (type of client, its last official version (1.9.0, 1.9.1, etc). Since generally speaking, there isn't any real way to fix old clients (if someone is still using 1.8.0 client, making a patch for known bugs to that client isn't likely to help, as most likely, person isn't going to get it updated), there could already be a pretty large list of exploits. Things like 'if client is older than 1.9.1, these bugs exist which I could exploit'. Whether the server knows the SVN number or not probably won't make a big difference. However, I do agree, there really isn't much reason for the server to know the SVN number. What would be more interesting, from a data collection standpoint, is knowing the number of people that are actually compiling out of SVN vs using officially downloaded clients. I'm not sure what I would do with that knowledge, other than to say 'hmm, interesting, x% of players get there client from SVN'. Related to that could be precompiled vs non precompiled clients somehow reporting that. However, that really is more dangerous. If a server admin was going to try to hijack a client, using a precompiled client is the way to do it. Any 'compile it yourself' client has so many variables (compiler options, version of the compiler, type of system it is compiled on) to make most all exploit bugs (typically buffer overflows) virtually impossible. However, if the developer can download the same client that players are using (precompiled), they can play around with the exploit, write the code that properly hijacks it, etc with a high level of success (different versions of some of the libraries may make a difference). So if anything, not having clients report their version doesn't make it harder for server admins, they just can't know who to target. And if the 'fixed' clients have some form of reporting (server abc sending bogus data that looks to be trying to exploit bug abc), and the server can't know which of those clients might report, that may make it so that the server admin won't try it. I would say that any server that is trying to do such things should be blacklisted from the metaserver (and potentially reported to the service provider). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Mark Wedel wrote: > Alex Schultz wrote: > >> Hmm, well I guess that is somewhat of an issue. What about having >> ./configure time option to make it very easy for server admins to decide >> if they want the revision number included in the version string sent to >> the metaserver? >> > It should be a settings option, not a configure option. Putting it in the > settings makes it a lot easier all around. Agreed. Actually, that thought happened to come to mind while I was bored at work today :) Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Alex Schultz wrote: > Brendan Lally wrote: >> I'm not sure it is such a great idea to send the revision number to >> the metaserver, certainly not if the metaserver is going to push that >> information out to clients, in that case, someone who wished to be >> annoying could look for servers with revisions predating certain bug >> fixes or balance tweaks and abuse or exploit them. > Hmm, well I guess that is somewhat of an issue. What about having > ./configure time option to make it very easy for server admins to decide > if they want the revision number included in the version string sent to > the metaserver? It should be a settings option, not a configure option. Putting it in the settings makes it a lot easier all around. configure options should really only be used for things that need a recompile to take affect (libraries, compiled in options, etc). It shouldn't be used for things that are easy to control at run time. It would also be pretty annoying to loose such a change because you re-run configure without specifying all the same options. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Brendan Lally wrote: > I'm not sure it is such a great idea to send the revision number to > the metaserver, certainly not if the metaserver is going to push that > information out to clients, in that case, someone who wished to be > annoying could look for servers with revisions predating certain bug > fixes or balance tweaks and abuse or exploit them. OTOH, this really isn't much different than right now. Server xyz is running 1.9.0, which doesn't have some bug fix in 1.9.1, etc. At some level, it becomes security through obscurity. And if we believe that 2.0 will take quite a while to finally get out and release, and that some servers may start running 2.0 for testing purposes, they may very well want to advertise their version. Of course, that is all up to the server - as far as the metaserver protocol is concerned, it is just a text string, so doesn't care what is in it (I could modify a server right now to claim it is version 2.5 for example). > > If you are talking about sending the revision as a seperate field to > the metaserver, that isn't for propagation to clients. then that is a > different issue altogether, and could provide useful information about > things like how quickly updates are made available in practice. Current metaserver protocol doesn't really support more fields. It wouldn't be hard to add. There was some discussion in the past about a new metaserver layout - that is a different discussion, but could be worth revisiting. > > Likewise, although the clients need only open a connection to the > metaserver to recieve the server list, having the official clients > send their revision numbers by default would give some indication as > to which versions of the clients are in use. (assuming the metaserver > were suitably modified to read that information from the socket). See note above. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Alex Schultz wrote: > A few times, tracking the svn revision instead of the $Id strings has > been brought up. IMHO this should be done, both in the client and > server. I propose we implement it as follows in both: > > Create a version.h file containing something like: > > #include "svnversion.h" > > #define BASE_VERSION "2.0.0-dev" It should actually get that version number from autoconf, like it does now. Then as part of that, for official releases, the -dev tag can be removed from configure.ac > In release tarballs, the "-dev" postfix to BASE_VERSION will be removed > and it will be adjusted to ignore SVN_REV. Then have a defaultly blank > svnversion.h file, which the building process will create simply in the > form of: > > #define SVN_REV "5678" > > The ./configure stage will check for the presence of .svn and the > svnversion command, while the build process will run svnversion. The check for .svn would be better done in the makefile. configure can check for svnversion. In addition, if the makefile doesn't find a .svn directory, or does not find svnversion, it should create a svnversion.h file with an empty SVN_REV, eg: #define SVN_REV "" To the best of my knowledge, there isn't really any way to include a file if it exists, don't include it if it doesn't. So it is just a lot simpler to always include it. You really don't want the svnversion.h file to be any part of SVN, because otherwise people will accidentally check it in and now have a version number that isn't correct. > The > build process running svnversion because not all revisions require > ./configure to be re-run. Also, it will only write svnversion.h if a > check shows that it was checked out from official crossfire svn, this is > to ensure all revision numbers correspond to the same repository. I think checking for official repository checkout is probably overkill and isn't needed. After all, if a developer really wants to have a bogus SVN_REV number, there are a lot easier ways to do it. > > This version would both be used in the client for outputing to the > console instead of the rcs-id values, and the server will use this > version for reporting to the metaserver as well as console output. Does > this model make sense to everyone? That sounds fine to me. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
On 10/13/06, Christian Hujer <[EMAIL PROTECTED]> wrote: > > > Likewise, although the clients need only open a connection to the > > metaserver to recieve the server list, having the official clients > > send their revision numbers by default would give some indication as > > to which versions of the clients are in use. (assuming the metaserver > > were suitably modified to read that information from the socket). > Oh that would make it easy for a bogus server to abuse or exploit known client > bugs to hack client machines. I apologise if I was unclear on that point, I'm talking about sending the information to the /metaserver/, not the individual servers for the purpose of determining client version usage rates. Currently the best guess as to which clients everyone is running is based on connections to metaforge, but most of these people probably query the metaserver first (since that is default behaviour). It would be nice to be able to tell roughly what versions everyone is running in terms of addressing issues of backwards compatibility (eg, is anyone using 1.4 or 1.5 still, and is it therefore safe to break compatibility? or, if a serious bug is found, is it worth making a new point release for a version that the majority of the userbase runs?) Likewise if the interface mode (gtk2, gtk, x11) were sent, then there would be some usage statistics to base the questions about client design on. I am thinking of something to go alongside http://crossfire.real-time.com/metaserver/ that instead of listing servers would list summary statistics for the clients, eg In the last week there were x client connections of which y were from unique IP addresses from n different countries. They were using the following versions: 1.7 ...% 1.7.1 ...% 1.8 ...% and so on. In terms of client abuse of servers though, I am thinking of annoying bugs and balance exploits and not security concerns. To give a recent example, if someone sees a server running revision <= 4995 then they may know they will be able to unequip cursed weapons by changing skill and abuse that bug, whereas it might not occur to them to check otherwise. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
On Friday 13 October 2006 19:15 Brendan Lally wrote: > On 10/13/06, Alex Schultz <[EMAIL PROTECTED]> wrote: > > A few times, tracking the svn revision instead of the $Id strings has > > been brought up. IMHO this should be done, both in the client and > > server. I propose we implement it as follows in both: > > > > > > > > This version would both be used in the client for outputing to the > > console instead of the rcs-id values, and the server will use this > > version for reporting to the metaserver as well as console output. Does > > this model make sense to everyone? > > I'm not sure it is such a great idea to send the revision number to > the metaserver, certainly not if the metaserver is going to push that > information out to clients, in that case, someone who wished to be > annoying could look for servers with revisions predating certain bug > fixes or balance tweaks and abuse or exploit them. Oh really? Yeah, there's so many different crossfire servers out there that I really need this information to choose the right ones to attack, otherwise the chances of finding a bogus one are hopeless ;-) (I hope it was obvious that I was ironic ;-) > If you are talking about sending the revision as a seperate field to > the metaserver, that isn't for propagation to clients. then that is a > different issue altogether, and could provide useful information about > things like how quickly updates are made available in practice. > > Likewise, although the clients need only open a connection to the > metaserver to recieve the server list, having the official clients > send their revision numbers by default would give some indication as > to which versions of the clients are in use. (assuming the metaserver > were suitably modified to read that information from the socket). Oh that would make it easy for a bogus server to abuse or exploit known client bugs to hack client machines. If balancing protecting clients from abuse vs. protecting servers from abuse, I'd say protecting clients is more important for several reasons: * There are more clients than servers (yes, even for crossfire ;-) * A typical client user puts blind trust in client software. * A typical server admins knows of the dangers of running public services. I definitely vote for including the server's revision in the meta server in public. This allows players to tell the mapset and set of bugfixes a server's most likely to be using. You could always make this field optional so anxious server admins can exclude that field from the metaserver information. I know that Brendan might have talked about game balance issues, not security concerns, yet I'm pro eventually optionally) including the server's revision in the metaserver. My 2 cents Cher :) -- Christian Hujer Free software developer mailto:[EMAIL PROTECTED] http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB pgp4biVXv9KTN.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
Brendan Lally wrote: > I'm not sure it is such a great idea to send the revision number to > the metaserver, certainly not if the metaserver is going to push that > information out to clients, in that case, someone who wished to be > annoying could look for servers with revisions predating certain bug > fixes or balance tweaks and abuse or exploit them. Hmm, well I guess that is somewhat of an issue. What about having ./configure time option to make it very easy for server admins to decide if they want the revision number included in the version string sent to the metaserver? Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN revions in version
On 10/13/06, Alex Schultz <[EMAIL PROTECTED]> wrote: > A few times, tracking the svn revision instead of the $Id strings has > been brought up. IMHO this should be done, both in the client and > server. I propose we implement it as follows in both: > > > > This version would both be used in the client for outputing to the > console instead of the rcs-id values, and the server will use this > version for reporting to the metaserver as well as console output. Does > this model make sense to everyone? I'm not sure it is such a great idea to send the revision number to the metaserver, certainly not if the metaserver is going to push that information out to clients, in that case, someone who wished to be annoying could look for servers with revisions predating certain bug fixes or balance tweaks and abuse or exploit them. If you are talking about sending the revision as a seperate field to the metaserver, that isn't for propagation to clients. then that is a different issue altogether, and could provide useful information about things like how quickly updates are made available in practice. Likewise, although the clients need only open a connection to the metaserver to recieve the server list, having the official clients send their revision numbers by default would give some indication as to which versions of the clients are in use. (assuming the metaserver were suitably modified to read that information from the socket). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN revions in version
A few times, tracking the svn revision instead of the $Id strings has been brought up. IMHO this should be done, both in the client and server. I propose we implement it as follows in both: Create a version.h file containing something like: #include "svnversion.h" #define BASE_VERSION "2.0.0-dev" #ifdef SVN_REV #define VERSION BASE_VERSION"-r"SVN_REV #else #define VERSION BASE_VERSION #endif In release tarballs, the "-dev" postfix to BASE_VERSION will be removed and it will be adjusted to ignore SVN_REV. Then have a defaultly blank svnversion.h file, which the building process will create simply in the form of: #define SVN_REV "5678" The ./configure stage will check for the presence of .svn and the svnversion command, while the build process will run svnversion. The build process running svnversion because not all revisions require ./configure to be re-run. Also, it will only write svnversion.h if a check shows that it was checked out from official crossfire svn, this is to ensure all revision numbers correspond to the same repository. This version would both be used in the client for outputing to the console instead of the rcs-id values, and the server will use this version for reporting to the metaserver as well as console output. Does this model make sense to everyone? Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN notes/thoughts
Hi, On Monday 25 September 2006 23:09 Nicolas Weeger (Laposte) wrote: > > I think similar logic could also be used to embed the version number > > into the client and server binaries. That way, when someone reports a > > bug, it is very clear what version they are running. By using a state > > file, it means we don't need to recompile and relink everytime (if we > > just used svnversion to blindly write a .c/.h file, then everytime it > > would recompile and relink that component). > > Agreed, having the exact revision number would be really nice to see the > exact issue. I agree and highly recommend this (using revision number). I use it in Gridarta for a long time already. You actually can get the last change revision number instead of the latest update revision number out of the subversion client: svn info --xml doc | xql /info/entry/commit/@revision -cv XML is such a wonderful thing (read: Life can be so easy ;-) $ rpm -qf $(which xql) perl-XML-XQL-0.68-150 > > In both of these cases, we also need to handle the case for the > > official releases, where there will not be any SVN information in the > > downloaded source code, and the user may not even have svn tools > > installed. > > Well, that's what tags/branches are for, i guess :) Yes. If used correctly, a release tag semantically is nothing else but a symbolic name assigned to a specific repository revision. (The symbolic name is assigned using svn cp, and please use svn cp with remote URLs for that, creating a symbolic name locally neither makes sense nor is it a lot of fun) Cher :) -- Christian Hujer Free software developer mailto:[EMAIL PROTECTED] http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB pgp3Aixuoe92b.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN notes/thoughts
> One point is automatically rebuilding the archetypes when the arch tree > changes. > > My thought here is that lib/Makefile can run svnversion and puts that in > a state file (.collect.svn.new). Then, the process compares that file with > the old one (.collect.svn) - if different, it runs the collect and moves > the file over. If the same, it just doesn't do anything. > > In this way, a collect would automatically be done whenever the > archetypes are updated. Sounds like a good idea to me, if possible :) > I think similar logic could also be used to embed the version number into > the client and server binaries. That way, when someone reports a bug, it > is very clear what version they are running. By using a state file, it > means we don't need to recompile and relink everytime (if we just used > svnversion to blindly write a .c/.h file, then everytime it would recompile > and relink that component). Agreed, having the exact revision number would be really nice to see the exact issue. > In both of these cases, we also need to handle the case for the official > releases, where there will not be any SVN information in the downloaded > source code, and the user may not even have svn tools installed. Well, that's what tags/branches are for, i guess :) > In the case of lacking the svn data itself, I'd think the makefiles could > just check for .svn files - I'd rather not have to reconstruct the > makefiles for the official versions. In terms of the version string, I > think the file that inclues it would have to be part of the distributed > version so that it is there for the compiled in. Including the SVN version > in officially released distributions shouldn't cause any problems IMO. No issue for me either. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN notes/thoughts
Been a few days since we moved to SVN. With the transition, there are some changes that can be made. One point is automatically rebuilding the archetypes when the arch tree changes. My thought here is that lib/Makefile can run svnversion and puts that in a state file (.collect.svn.new). Then, the process compares that file with the old one (.collect.svn) - if different, it runs the collect and moves the file over. If the same, it just doesn't do anything. In this way, a collect would automatically be done whenever the archetypes are updated. One minor issues is that svnversion reports the version the respective tree is updated to. Given that all of crossfire is in the same crossfire repository, you do get the case where the number of svnversion can be different, but for the actual component, there haven't been any changes made. This is because svnversion returns the version that the tree is at, relative to last update. Real life example below: [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (591) % svnversion . 4963 [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (592) % svn update At revision 4969. [hugin:/export/home/crossfire/crossfire-SVN/arch/trunk] (593) % svnversion . As you can see, there were no changes in the arch tree relative to the versions, yet svnversion returns a different value. What this really means is that such a method would result in archetypes being recollected more often than strictly necessary. OTOH, unless you update the arch tree, this isn't an issue. I think similar logic could also be used to embed the version number into the client and server binaries. That way, when someone reports a bug, it is very clear what version they are running. By using a state file, it means we don't need to recompile and relink everytime (if we just used svnversion to blindly write a .c/.h file, then everytime it would recompile and relink that component). In both of these cases, we also need to handle the case for the official releases, where there will not be any SVN information in the downloaded source code, and the user may not even have svn tools installed. Configure can easily enough be updated to look for svnversion to cover that case. In the case of lacking the svn data itself, I'd think the makefiles could just check for .svn files - I'd rather not have to reconstruct the makefiles for the official versions. In terms of the version string, I think the file that inclues it would have to be part of the distributed version so that it is there for the compiled in. Including the SVN version in officially released distributions shouldn't cause any problems IMO. thoughts/comments? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
Mark Wedel wrote: > In terms of branching, as mentioned, I'm usually the one most hit by this. >But to me, the real show stopper here is ability to have a nice merge >functionality. CVS isn't that great - if the there are no conflicts, no >problem, but if there are, CVS just brackets the code where there is an issue, >leaving you to fix it in your favorite editor. I don't know if SVN is any >better. Some other products I have seen do have a nice GUI, letting one >select >which line/block to take. I think there are graphical CVS tools, so maybe >they >do something similar. > > From what I can see, SVN is on par with this. It does it slightly differently, but not really any easier looking or harder looking. > But the real problems with branches is that I don't think there are > currently >enough people using crossfire that a branch gets much usage. One idea tossed >out was to put experimental code in the branch, but if no one uses the branch, >doesn't do much good. > > Well, SVN does have a significant advantage here. From what I can see, it is very easy, by either using SVN, or svn-mirror, to have a local mirror of the SVN tree on your computer, that you can use as a 'local branch'. That also has the advantage that within your local branch, you could revert little changes very easily if you were committing to your local branch step by step. The whole time you can have it sync with the main SVN server, and eventually merge your changes back to the main svn server (preserving the individual commits). IMHO, using SVK or svn-mirror, syncing with a sourceforge svn server, would solve such branching issues very nicely without cluttering the remote server. > One complaint I do have with CVS, and I don't know if SVN is better, is that >CVS will bring back code I delete. > > Say for example I'm editing a file, and remove the function foo() as well as >make some other changes. Someone else makes some change to the file and >commits. I do a cvs update, and foo() is now back in my file - even though no >where along the process were any changes made to foo() itself. So then I have >to go and delete again. Branches may make that a little cleaner. > > Not sure if SVN is any better either, though the branching as I was talking about above could possibly help. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
Nicolas Weeger wrote: > Hello. > > Apparently Sourceforge now has SVN up, and you can import CVS repository > directly. > See http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 > for details > > Maybe we could think of moving Crossfire to SVN? Couple quick notes from my side on this discussion: I'd generally say that to make a switch, what we are switching to has to be clearly better. Making a near even trade may not be a good trade just because of the effort to make the switch (all developers need to install SVN software, I'd think also that if you have work in progress, you'll have to manually move that over to SVN environment, etc). There is also perhaps something to be said that CVS is probably more standard. To tell people to use cvs to checkout latest version (and provide them the cvs command), good chance they probably have cvs client installed. Not sure how wide spread SVN is either. In terms of specific features: Renames don't happen that often, but sometimes do happen. I think this mostly happens regarding stuff in the arch tree - being able to keep revision history on a move would be nice, but most files in the arch tree don't have much a history, or if they do, isn't very interesting. Where we do very infrequently run into problems is when a file/directory has been deleted and we want to re-add it as a different type (file->directory, or vice versa). CVS doesn't like that. You can resuscitate the file if it is of the same type, but not different types. I can't remember last time this came up - long time back, but does come it once in a very rare while. Getting specific versions as tchize describes is interesting, but not something I have used often. I do symbolic tag the official releases, so if you want to get release 1.4.0, just use the tag rel-1-4-0 with CVS. Once in a rare while, I'll also want to look at the state of things before some specific checkin, but doing a checkout based on date has been sufficient so far (cvs commits are automatically date stamped). I don't know how many people view the CVS tree through the web page, so not positive how much benefit we get by SVN making more useful information available. In terms of branching, as mentioned, I'm usually the one most hit by this. But to me, the real show stopper here is ability to have a nice merge functionality. CVS isn't that great - if the there are no conflicts, no problem, but if there are, CVS just brackets the code where there is an issue, leaving you to fix it in your favorite editor. I don't know if SVN is any better. Some other products I have seen do have a nice GUI, letting one select which line/block to take. I think there are graphical CVS tools, so maybe they do something similar. But the real problems with branches is that I don't think there are currently enough people using crossfire that a branch gets much usage. One idea tossed out was to put experimental code in the branch, but if no one uses the branch, doesn't do much good. One complaint I do have with CVS, and I don't know if SVN is better, is that CVS will bring back code I delete. Say for example I'm editing a file, and remove the function foo() as well as make some other changes. Someone else makes some change to the file and commits. I do a cvs update, and foo() is now back in my file - even though no where along the process were any changes made to foo() itself. So then I have to go and delete again. Branches may make that a little cleaner. One other note regarding SVN on sourceforge - with CVS, we can basically use whatever scripts we want for checkin (current e-mail notification being one). With SVN, only a few specific scripts are allowed, and it seems that only there versions are allowed. I don't know if that actually makes much difference or not - I suppose it depends on what the output of their commit script looks like. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
Alex Schultz wrote: >Yes, this indeed a current revision control issue. Personally I try to >keep to the former of those two and avoid the later like the plague. >Then try to minimize the affect, instead of making monolithic changes, >figuring out a way to split a large task into many subtasks, as many of >the subtasks as possible being usable for purposes other than the larger >task too (i.e. what I've been doing for land plots and required >features). However that is not always possible to split like that and >even then some sort of revision control on "local branches" would be good. > Adding to what I just said, perhaps some developer usage of svk ( http://svk.elixus.org/ ) would be helpful for local branches. It is capable of syncing with both svn and cvs (not sure how good such syncing with cvs is for local branches, but apparently it's great for svn). Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
Lalo Martins wrote: >Sure, because CVS makes it inconvenient. And with SVN, you will still >not branch. However, crossfire *should* be branching much more often, >and it would if it used a reasonable revision control system. > >Right now what happens instead is either: > >- developer writes complicated code on his machine, over the course of, >from a few days to a few weeks. This requires constantly catching up >with cvs, and there is no revision control for this "local branch" - if >you make a mistake and kill some code you later decide you wanted after >all, you have to write it again. Then developer commits it in a big >batch. This happens specially to MWedel. > >- developer codes incrementally, using CVS, often leaving users with the >incomplete feature. > Yes, this indeed a current revision control issue. Personally I try to keep to the former of those two and avoid the later like the plague. Then try to minimize the affect, instead of making monolithic changes, figuring out a way to split a large task into many subtasks, as many of the subtasks as possible being usable for purposes other than the larger task too (i.e. what I've been doing for land plots and required features). However that is not always possible to split like that and even then some sort of revision control on "local branches" would be good. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
This is the 999th (ish) similar discussion I had in the last few months :-P so I figured it was about time to blog a summary: http://lalo.revisioncontrol.net/blog/lalo/#entry:24 Highlights: And so says Tchize on 21/03/06 17:45... > On the point of merging / branching problem, may i point > out we never branched / merged in crossfire history? Sure, because CVS makes it inconvenient. And with SVN, you will still not branch. However, crossfire *should* be branching much more often, and it would if it used a reasonable revision control system. Right now what happens instead is either: - developer writes complicated code on his machine, over the course of, from a few days to a few weeks. This requires constantly catching up with cvs, and there is no revision control for this "local branch" - if you make a mistake and kill some code you later decide you wanted after all, you have to write it again. Then developer commits it in a big batch. This happens specially to MWedel. - developer codes incrementally, using CVS, often leaving users with the incomplete feature. > - command line as easy as CVS one for checkouts/commit and very similar, > only repository location changes (enough for most devels to easily use it) Well, CVS is even more similar :-P Seriously, other, REAL revision control systems also have command lines similar to CVS. Bazaar-NG, which is my recommendation, is quite similar, in the commands that have a parallel in CVS at all. > - tracking of rename / move / deletions (this is, i think what prevented > us in the past various reorganisations of code) That's the only one where I agree. I just don't think it's worth the pain. > - svn commits are done in transaction (This is an important point with > sf because due to load on sf, the cvs connections are regulary timed > out, leaving the CVS in an undetermined stated where not all files get > commited) Non sequitur... there are others, different ways to get an inconsistent svn, and when you do, you mess up the whole repository. > - revisions, tags and branches are easily accessible from a webbrowser. > (in viewCVS you needed to go to each file an select a specific version > if you wanted to explore a previous state of CVS) Sounds cool, in practice it doesn't make a difference at all. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
Just adding my anectdotes: We've used SVN at work for almost two years now. I constantly miss it when using CVS, but once every couple of weeks the repository locks up and the admin (me) has to restart apache & recover the repositories (it takes just a few seconds). There are also a couple of ways to DOS attack the system that our testers have unintentionally done when commiting their testfiles... Nothing has been hard to fix, but I don't know how quick the SF admins are at noticing such things and fixing them. On the other hand, if the repository is down, one can still check what files has been modified, make diffs and revert them back to the original. Regards, /Sebastian -- .oooO o,o Oooo. Ad: http://dum.acc.umu.se/ ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
+1 for switch to svn I have used svn here, i find it ways more usefull then CVS to manipulate. Getting a specific version of repository is easier, you have revision history not only on files but also on directory. You can attach metadatas on a document, leaving informations there for others. Also, revision history covers the whole repository, making it a complete set, while in cvs each file had his own version (to get a specific state of cvs you had to guess somehow a date you wanted to go, in svn you read the version number of offending commit and you checkoout version-1 of repository). On the point of merging / branching problem, may i point out we never branched / merged in crossfire history? But to me, the most importants assets of SVN are: - command line as easy as CVS one for checkouts/commit and very similar, only repository location changes (enough for most devels to easily use it) - tracking of rename / move / deletions (this is, i think what prevented us in the past various reorganisations of code) - svn commits are done in transaction (This is an important point with sf because due to load on sf, the cvs connections are regulary timed out, leaving the CVS in an undetermined stated where not all files get commited) - revisions, tags and branches are easily accessible from a webbrowser. (in viewCVS you needed to go to each file an select a specific version if you wanted to explore a previous state of CVS) Please also note the 'limitations' in sf page also apply to cvs (case sensitivity, restricted file names, permanent removal) As of speed of svn, it is due to transactionnal layer, it shouldn't affect us very much, we don't have hundreds of devel attempting concurrent commits :) I am gald to see sf finally decided to offer svn support, but i wonder since how long they do provide it, maybe it is worth waiting a bit for sf to fix any issue that can arise from their svn configurations. Regards, Tchize Nicolas Weeger a écrit : >Hello. > >Apparently Sourceforge now has SVN up, and you can import CVS repository >directly. >See http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 >for details > >Maybe we could think of moving Crossfire to SVN? > >Nicolas > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
Nicolas Weeger wrote: >Hello. > >Apparently Sourceforge now has SVN up, and you can import CVS repository >directly. >See http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 >for details > >Maybe we could think of moving Crossfire to SVN? > >Nicolas > Under the assumption nothing breaks, I'm indifferent. I don't see it solving much, but I personally do not see the harm in it either. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
On Tue, Mar 21, 2006 at 10:10:26AM +0800, Lalo Martins wrote: > And so says Nicolas Weeger on 21/03/06 05:31... > > > > Maybe we could think of moving Crossfire to SVN? > > -1 > > SVN has very few advantages over CVS (well, you can move/rename files > and dirs, and... hmm... yeah), and a few disadvantages (branching and -1 too (but i'm no cf devel at sf.net, so don't really count that :) I've had more bad experiences with svn than with cvs all the time before. IMHO svn is still not as stable as cvs. Robin -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Robin Redeker ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
And so says Nicolas Weeger on 21/03/06 05:31... > > Maybe we could think of moving Crossfire to SVN? -1 SVN has very few advantages over CVS (well, you can move/rename files and dirs, and... hmm... yeah), and a few disadvantages (branching and merging is much, much more usable in CVS). I don't really think it's worth the time to do it and the users' and developers' time to switch; I'm sure there are a few developers who will still have to learn it. If you want to move to bzr, darcs, monotone, git, mercurial, or something like that, then I'm all for it. SVN is a mistake, though. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical:http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] SVN?
Hello. Apparently Sourceforge now has SVN up, and you can import CVS repository directly. See http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 for details Maybe we could think of moving Crossfire to SVN? Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
