Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: Mark Wedel wrote: Current status: CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. I've also made 1.x branches of the arch, client, maps, and server (at such time it becomes relevant, it could be done for jxclient and sounds). There are as arch/branches/1.x, client/branches/1.x, etc. snip So as of now, should we be committing to SVN as opposed to CVS, and using the 1.x branch and trunk as has been planned? :) Yes. In fact, I don't think anyone will be able to commit to CVS, as I've revoked everyones CVS access (seems only real way to prevent accidental checkins, etc) Btw, one thought is it would probably be good to make some sort of clear documentation for the usage of the 1.x branch and trunk and the branching plan. You mean like: http://wiki.metalforge.net/doku.php/crossfire_release_cycle That should probably be put someplace more prominently. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
On Wed, 20 Sep 2006 00:02:48 -0700, Mark Wedel [EMAIL PROTECTED] wrote: [...] Yes. In fact, I don't think anyone will be able to commit to CVS, as I've revoked everyones CVS access (seems only real way to prevent accidental checkins, etc) Just a little note about that: those who used the developer access to CVS (over SSH) will find that operations like cvs update, cvs status or cvs diff do not work anymore. You have to change the CVS root and use the anonymous access instead of the developer access if you still want to check the status of your files or do a diff. I discovered this problem because although I had updated most of my checked out CVS trees last week, I saw yesterday that I forgot one of them. I wanted to do a cvs update or cvs status to check if I had any locally modified files or if I could just delete this tree, but the commands failed because the CVS access is now blocked for developers (cvs update fails because it cannot create the required lock file, so both the read and write access are effectively disabled). In case anyone here runs into the same problem and is unable to check the status of some old cvs trees, there is a simple solution: use a tool such as changecvsroot or changecvsroot.py (Python version handling subtrees in a better way) and replace :ext:[EMAIL PROTECTED]:/cvsroot/crossfire by :pserver:[EMAIL PROTECTED]:/cvsroot/crossfire in one go for your whole tree. This will now allow you to quickly check the status of your tree as an anonymous user and be sure that you can delete it without losing any locally modified files. -Raphaël ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Current status: CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. I've also made 1.x branches of the arch, client, maps, and server (at such time it becomes relevant, it could be done for jxclient and sounds). There are as arch/branches/1.x, client/branches/1.x, etc. Things that I still have yet to do, and will do tomorrow night: Use svn propset to make some virtual entries (link to gridarta for the edit, a link in server/lib/arch to link to archetypes), support for $Id$ in files. Also, should make some 'virtual' directories with links to all he relevant pieces. Eg, have a 'complete' or 'latest' directory which can get all the */trunk entries, so easy to get all those. Likewise, probably have a stable directory which links to the 1.x entries. That said, there is nothing preventing developers from checking out the SVN and actively using it - the things left to do above should not affect that. Mark Wedel wrote: Just a note/reminder of this change: Crossfire will switch from CVS to SVN this onday, Sept 18. What will happen: - Current CVS repository will remain available for read-only access, but no future changes will be made to that repository. The CVS repository will purely be for historical reasons (want to see what 1.6 looked like, etc.) Developer permissions will be updated to remove CVS write permissions. The crossfire page on sourceforge will also be updated so that CVS info will not appear. - The SVN repository will only import the head trunk, and not the tags or branches of the CVS repository. Future tags and branches will be made of course. - Only actively developed portions from CVS will be moved over. - Instead of having a copy of the editor in crossfire, we will link to the Gridarta project. - Some amount of cleanup in the repositories will be done - mainly, this means that some automatically generated files will not be included (flex files, collected archetypes/images/etc). The autoconf/automake files will stay in the repository, as it is general practice that code can be downloaded and then a simple configure run. - The server portion will be renamed from 'crossfire' to 'server' to more accurately describe what portion it is. - The organization will be server/trunk, client/trunk, client/branches, etc. After the fact: - The server and client will need some updating to get the version number so they can print that out as a build revision (instead of showing revision of each file). - Branches for 1.x will be made for the different components. - Likely some other cleanup will be necessary. ___ 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] CVS - SVN conversion
Mark Wedel wrote: Current status: CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. I've also made 1.x branches of the arch, client, maps, and server (at such time it becomes relevant, it could be done for jxclient and sounds). There are as arch/branches/1.x, client/branches/1.x, etc. snip So as of now, should we be committing to SVN as opposed to CVS, and using the 1.x branch and trunk as has been planned? :) Btw, one thought is it would probably be good to make some sort of clear documentation for the usage of the 1.x branch and trunk and the branching plan. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
CVS data is imported over, and I've renamed the files to be arch/trunk, client/trunk, etc. snip Thanks Mark for handling the conversion! Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Nicolas Weeger (Laposte) wrote: flex files that generate .c (loader.c) - not a big space user, yet at the same time, pretty trivial for most people to generate (probably any system that has gcc can pretty easily install flex if not already there). The flex files do not change very often. The one question might be windows (can they easily be regenerated there?). Given these are small files, I'm sort of mixed on these. The version of flex used to generate these files really doesn't have any impact on performance - I don't think we've ever had an issue where someone had a bad version of flex installed that caused problems. Windows users can generate loader.c with flex, already done that. Just need to ensure the right flags are used (iirc case-insensitivity, for instance). Ok - so maybe leave out the flex generated files then. rebuilt lib files (Archetypes, images, etc): These are the files I'm most inclined to leave out of SVN. The images tend to be quite big (slowing down updates). Plus, the updates are rather inconsistent - they are not updated after every change is made to an arch, but rather when someone remembers to or is some critical need. Within SVN, we can set up lib/arch to point to the actual arch tree, so an update of the server also gets updated arches. Plus, we already have all the tools in place to collect them (the collect.pl script), so this doesn't add any additional software dependencies. If anything, this may actually help people use the updated archs. The only issue with that is that archs would now be part of the whole crossfire module. Thus changing an arch will make a new server version. Unless i'm wrong? If my understanding correct, the revision number will be unique for each of the different modules (arch, client, etc). Even if it isn't, that really isn't much different than if we have the collected ones - then when you collect the archetypes and check them in, that is updating the revision number, even though nothing in the server really changed. Right now, the archetypes file is not updated every time and arch file is updated, but in theory it could be. If anything, not having the collected files in the server tree would mean less server revisions. Maybe 1 out of 10 (or 20) commits to the server is just a recollection of the archetypes, etc, and those wouldn't be needed anymore BTW, while we're at messing with stuff, shouldn't crossfire be renamed to server? There is really two issues here: 1) What is the module called within SVN. In this case, I agree we should rename it server. 2) What is the executable that module makes is called. This is really independent of the point above. It should be renamed crossfire-server of cf-server of the like, but that is a change that should be made in the main head branch for the 2.0 release. As a note, for any files that we automatically generate that are not normally in SVN (if we so decide) yet are in the distributions we ship out, I'd expect they would be in the release branch of the SVN repository for that release (so you can go to the 1.10 branch and see what the archetypes file had, or see what the makefile looked like, etc). Although, maybe even that is useless - could always just download the old releases. As a remark, I'd say to automate stuff as much as possible in that case. That is make a nice script building everything, collecting archetypes, generating tarballs, all this stuff. Even if it only takes 15m to do by hand, that becomes a pain fast :) (talking from Windows experience, where i should definitely automate things!) The makefiles will already recollect archetypes and build the flex files as needed. So in a sense, the only extra work is to add those files in the repository. But that part can certainly be in a script. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. Actually, it isn't the default, but easy enough to do it that way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Mark Wedel wrote: It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. Actually, it isn't the default, but easy enough to do it that way. Except I can't see a way to do it in sourceforge. To do it, you would need multiple repositories. However, best I can tell, with sourceforge, 1 project == 1 repository. So to do this on sourceforge would entail having multiple projects, which gets into other administrative issues (each project would have its own developer lists with permissions, etc). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
A copy of the crossfire data is now in svn.
Note: This is only a test copy for experimentation, and will be blown away on
Monday Sept 18. Do not commit any real changes - still put those in CVS.
to check it out:
svn co
https://svn.sourceforge.net/svnroot/crossfire/trunk/{client|arch|crossfire, etc}
edit files. To commit:
svn commit
I had some issues getting the commit to work, but now that it is working, it
seems to cache the data.
I think the issue may be that while the developer permissions within
sourceforge show that everyone has SVN access (everyone that is a developer),
things started working better when I unchecked that for myself, updated it,
then
checked it again, and updated. Probably a matter of it having to put some
files
in the svn tree.
I haven't gone through and updated everyones permissions for that - it'd be
curious if this is the real fix, or in my mucking of other things, I fixed the
problem.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
On Mon, 11 Sep 2006 22:37:04 -0700, Mark Wedel wrote: What I think I'll probably do is only import the main trunk from CVS. There really isn't any reason to import any of the branches - those will still exist in CVS, and I don't think any of them are active. That's what I figured. 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] CVS - SVN conversion
flex files that generate .c (loader.c) - not a big space user, yet at the same time, pretty trivial for most people to generate (probably any system that has gcc can pretty easily install flex if not already there). The flex files do not change very often. The one question might be windows (can they easily be regenerated there?). Given these are small files, I'm sort of mixed on these. The version of flex used to generate these files really doesn't have any impact on performance - I don't think we've ever had an issue where someone had a bad version of flex installed that caused problems. Windows users can generate loader.c with flex, already done that. Just need to ensure the right flags are used (iirc case-insensitivity, for instance). rebuilt lib files (Archetypes, images, etc): These are the files I'm most inclined to leave out of SVN. The images tend to be quite big (slowing down updates). Plus, the updates are rather inconsistent - they are not updated after every change is made to an arch, but rather when someone remembers to or is some critical need. Within SVN, we can set up lib/arch to point to the actual arch tree, so an update of the server also gets updated arches. Plus, we already have all the tools in place to collect them (the collect.pl script), so this doesn't add any additional software dependencies. If anything, this may actually help people use the updated archs. The only issue with that is that archs would now be part of the whole crossfire module. Thus changing an arch will make a new server version. Unless i'm wrong? BTW, while we're at messing with stuff, shouldn't crossfire be renamed to server? As a note, for any files that we automatically generate that are not normally in SVN (if we so decide) yet are in the distributions we ship out, I'd expect they would be in the release branch of the SVN repository for that release (so you can go to the 1.10 branch and see what the archetypes file had, or see what the makefile looked like, etc). Although, maybe even that is useless - could always just download the old releases. As a remark, I'd say to automate stuff as much as possible in that case. That is make a nice script building everything, collecting archetypes, generating tarballs, all this stuff. Even if it only takes 15m to do by hand, that becomes a pain fast :) (talking from Windows experience, where i should definitely automate things!) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
On Tuesday 12 September 2006 07:35 Mark Wedel wrote: Actually, from what I gather, it seems unlikely someone would do a svn checkout at the top of the repository. The reason being is that if you do that, you'll also get all the branches, which would amount to a pretty huge amount of data. I doubt people would even checkout out all the trunks, but maybe wrong on that. So that probably isn't as much an issue. Did you already think about how to organize the repository? The main question is: Do you want to apply ttb to maps, client, server etc. independently or one for all? Module-Individual ttb: /modulename/trunk /modulename/tags /modulename/branches Global ttb: /trunk/modulename /tags/modulename /branches/modulename Technically, I'd usually prefer the Module-individual ttb. If so, it would be a good idea to provide a virtual module named complete (or something better, I'll just assume the name complete for this example), probably with trunk only, where trunk has svn:externals set to include the trunks of the other modules: cd complete; svn propset svn:externals maps https://subversion.sourceforge.net/svnroot/crossfire/maps/trunk client https://subversion.sourceforge.net/svnroot/crossfire/client/trunk; etc.. Cu :) -- Christian Hujer Free software developer mailto:[EMAIL PROTECTED] http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB pgps4sPiuU504.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Nicolas Weeger (Laposte) wrote: rebuilt lib files (Archetypes, images, etc): These are the files I'm most inclined to leave out of SVN. The images tend to be quite big (slowing down updates). Plus, the updates are rather inconsistent - they are not updated after every change is made to an arch, but rather when someone remembers to or is some critical need. Within SVN, we can set up lib/arch to point to the actual arch tree, so an update of the server also gets updated arches. Plus, we already have all the tools in place to collect them (the collect.pl script), so this doesn't add any additional software dependencies. If anything, this may actually help people use the updated archs. The only issue with that is that archs would now be part of the whole crossfire module. Thus changing an arch will make a new server version. Unless i'm wrong? SVN doesn't have a concept of modules, instead it would simply be directories containing each, but one can check out an individual directory just as easily as if it was a module, and acts for most intents as a module. Due to that, a the revision number would increment as you say, regardless of if we leave the collected archetypes out or not. IMHO that's not a bad thing, as much as simply the way things are. BTW, while we're at messing with stuff, shouldn't crossfire be renamed to server? Or perhaps cfserver instead and make the client cfclient? Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: SVN doesn't have a concept of modules, instead it would simply be directories containing each, but one can check out an individual directory just as easily as if it was a module, and acts for most intents as a module. Due to that, a the revision number would increment as you say, regardless of if we leave the collected archetypes out or not. IMHO that's not a bad thing, as much as simply the way things are. Ok, I'm a fool, ignore most of what I just said there, it depends on how we have the ttb set up (see Christian Hujer's mail on that), but either way I don't think whether we leave collected archetypes of not will affect it Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Mark Wedel wrote: Another question for everyone: It has been commented/asked several times in the past whether the automatically generated files should be in the repository, or if it should be up to the developer to rebuild them. There are several types of files, and my general thoughts: snip Seems like good ideas to me. The only thing which I'm not sure if there is any way to do is have some file, ideally automatically created, that sits in the arch tree so that the server can know that the archs have changed and it should do a collect. One can manually run the command now, and there is a hidden timestamp file, but that file doesn't do any good if it never changes. I don't think there's a way to automatically update such a file, unless we could get special permission from sf.net to use a custom serverside hook, however I doubt they would allow it. However, if we store the arch tree and server tree with separate ttb as mentioned in Christian Hujer's mail, we might be able to use svn revision numbers to determine if it's been updated. As a note, for any files that we automatically generate that are not normally in SVN (if we so decide) yet are in the distributions we ship out, I'd expect they would be in the release branch of the SVN repository for that release (so you can go to the 1.10 branch and see what the archetypes file had, or see what the makefile looked like, etc). Although, maybe even that is useless - could always just download the old releases. Seems like a good idea. As noted by Nicolas it would probably be nice to automate that process to some degree as well. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Christian Hujer wrote: On Tuesday 12 September 2006 07:35 Mark Wedel wrote: Actually, from what I gather, it seems unlikely someone would do a svn checkout at the top of the repository. The reason being is that if you do that, you'll also get all the branches, which would amount to a pretty huge amount of data. I doubt people would even checkout out all the trunks, but maybe wrong on that. So that probably isn't as much an issue. Did you already think about how to organize the repository? The main question is: Do you want to apply ttb to maps, client, server etc. independently or one for all? Module-Individual ttb: /modulename/trunk /modulename/tags /modulename/branches Global ttb: /trunk/modulename /tags/modulename /branches/modulename Technically, I'd usually prefer the Module-individual ttb. If so, it would be a good idea to provide a virtual module named complete (or something better, I'll just assume the name complete for this example), probably with trunk only, where trunk has svn:externals set to include the trunks of the other modules: cd complete; svn propset svn:externals maps https://subversion.sourceforge.net/svnroot/crossfire/maps/trunk client https://subversion.sourceforge.net/svnroot/crossfire/client/trunk; etc.. It will be module individual ttb - that is the default, and I think the best way to go - keeps things like branches and what not a bit more managable. This also matches the current CVS setup - there are different top level entries that can be checked out. SVN does present some more options, since external references can be done, etc. I'm not sure how much use an ability to check out all the main trunks would get used - maybe for the home hacker. But I imagine for most public servers, they probably don't want the editor or client, etc. But I suppose there is no real harm to add something like that, whether or not people use it or not. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Mark Wedel a écrit : 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. I thik there may be modules that support it, but sourceforge is very particular in what modules they support (short list being ones that provide e-mail notification, and another that checkes file names for reasonable compliance). There may be client side scripts that could be used, but then that seems a little more problematic (some developers forget to use/install them, so their commits are not updated, etc). Does it just make sense to pull the $Id strings out of the files then? Well, the $Id strings have never seemed terribly useful to me (it was often more convenient for me to just check the timestamp of the build and/or source directory if I wanted to know when in CVS it was built from), however if anyone has any use for them, probably wouldn't be difficult to make a script to generate a .h file containing macros of that data, and put that in as part of the build system. The client had been modified at one point to provide that information, just to be more helpful in bug reports. That said, I agree that the header in each file probably isn't necessary. It might be nice to include the svn commit number in a header file, so that could be displayed, eg, the client could say something like: Crossfire Client 1.10 build 8963 Such that if a user reports a bug, we can easily check that global revision number and see if the bug may have been fixed, etc. Yes client has been modified in past to provide id of different modules. However those were made because CVS had no notion of global version numbers and it was the most easy way to find out which cvs version the user was using when reporting bug. Using the global svn revision number + branch can replace this Crossfire gtk client 2.1.0 (/branches/XYZW/client revision 1234) Branch name is important to include in bug report as well as revision number :-) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Tchize [EMAIL PROTECTED] writes: Crossfire gtk client 2.1.0 (/branches/XYZW/client revision 1234) Branch name is important to include in bug report as well as revision number This seems like a good idea to me. A couple notes though: -I think version number should have -dev appended if it's from svn, only removed for releases. -If it's from the trunk branch, probably would be good to make the message just like: Crossfire gtk client 2.1.0-dev (trunk revision 1234) as opposed to including the full branch path. -If it's from an unofficial (not on sf.net) branch, it should make the message like: Crossfire gtk client 2.1.0-dev (http://foo.bar.baz/svnroot/crossfire revision 1234) using the full path/url to the svn repository in place of branches/XYZW/client -Would it be a good idea to also put support for some other version control systems in the script to make the revision strings? I think it would be a good idea if it isn't too difficult, because making local branches of an svn repository can be easy with svk and bzr-svn, both of which can pull and push with normal svn repositories. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
On Mon, Sep 11, 2006 at 12:18:53PM -0500, ERACC Subscriptions wrote: On Sunday 10 September 2006 06:11 pm Mark Wedel wrote: I have put work on all my map edits on hold until the conversion. I have no clue how to use SVN to download updates and commit updates. Do we have a simple FAQ on how to do this using ssh/id/password? (I hate using keys) I specifically need command line usage information for SVN as relates to sourceforge.net. IOW what is the equivalent of: cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/crossfire co maps-bigworld svn co https://[EMAIL PROTECTED]/svnroot/crossfire/trunk/maps-bigworld where trunk specifies the HEAD branch, instead of a specific branch for i.e. 1.x development cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/crossfire commit When you are working inside your working copy, svn already has all of the information regarding to the repo-location so it is simply: 'svn ci' or 'svn commit' More info can be found at 'http://sourceforge.net/docs/E09' Regards, Stefan ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
I don't know if you were even planning to, but for the record, don't bother converting my pupland branch. It's easier for me to do it manually (or rather, from the existing bzr branch), since the conversion will be lossless -- Subversion and bzr understand file and directory moves, while CVS doesn't, and lots of the work I've done is directory moves. 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] CVS - SVN conversion
Mark Wedel wrote: Lalo Martins wrote: I don't know if you were even planning to, but for the record, don't bother converting my pupland branch. It's easier for me to do it manually (or rather, from the existing bzr branch), since the conversion will be lossless -- Subversion and bzr understand file and directory moves, while CVS doesn't, and lots of the work I've done is directory moves. Can you provide more info on what should be exclude (branch-tag?) It is easy enough to exclude it in the conversion. I believe he means the branch by the name lalo-pupland. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Christian Hujer wrote: Hi all, Am Montag, 11. September 2006 01:11 schrieb Mark Wedel: 1) They don't have a conversion utility, but rather directions (using cvs2svn) to make the change. Well, they used to have a conversion utility: https://sourceforge.net/project/admin/svn_migration.php?group_id=nn (Replace nn with the project id of crossfire) Instructions: https://sourceforge.net/docs/E09#import But actually I never got that migration tool working, it always failed for me. That's what I used, but it doesn't do the conversion for you - running cvs2svn still has to be done by the end user, etc. Given that, whatever files we care about can be removed from the copy of the CVS data before it being converted, so we can clear out any data we want to. If this was 100% automatic, we wouldn't really be able to do that. 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. It does. It only has to be switched on for each file individually. It's done via svn propset svn:keywords Id filename For instance: cd sandbox ; find -type f -print0 | xargs -0 svn propset svn:keywords Id or if it's not that many files, especially none with whitespace in their name cd sandbox ; svn propset svn:keywords Id $(find -type f) Ah - very good. Looking at the docs, I see that SVN uses the global version number in the $Id$ strings, which is fine. What I'm not sure of is if there is some way to have a file that automatically gets updated with the latest version string. For example, it would be nice for the version.h file to get updated on every commit that is done, so that it always contains the latest commit ID. If that was done, there really isn't any need to have the $Id$ in each file - just print that global number. sure, there can be the odd cases of a person updating only portions of the tree and getting out of sync revision numbers. But if someone does that, they are really asking for broken behaviour anyways (who is to say that there isn't some interaction related to this - a file that isn't updated needs to be updated to properly work with other files) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: Well, that's assuming that developers do a checkout of the maps, client, server, archetypes, etc. in one checkout, as opposed to checking each out separately (though SVN doesn't have modules, one can always check out the server directory without the map directory) Actually, from what I gather, it seems unlikely someone would do a svn checkout at the top of the repository. The reason being is that if you do that, you'll also get all the branches, which would amount to a pretty huge amount of data. I doubt people would even checkout out all the trunks, but maybe wrong on that. So that probably isn't as much an issue. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS - SVN conversion
Alex Schultz wrote: Mark Wedel wrote: 2) The CVS respository does not appear it will go away, so after the conversion, both SVN and CVS access will be available. However, only updates should be done to SVN, so CVS will go out of date (but is still probably useful as a reference for older releases). IMHO it's not worth doing, but in theory it would be possible to use a tool like tailor to incrementally update the CVS copy every so often. I don't think it would be awfully useful, however just pointing this out in case someone does think something like that would be useful. Not sure about tailor, but IIRC, one of the issues with most of these conversion tools is they do not deal with branches very well (probably because the branch methods vary wildly - in the case of SVN, branches are basically new copies of the repository). I forgot to mention in my previous e-mail, one of the first things I'll do once we move to SVN is to make a branch for the 1.x releases (with the main/head branch being for 2.x). snip 3) Since we can decide what files to import or not import, it may be a reasonable time to clean up some of the directories in the CVS root tree right now (eg, not move them to SVN), particularly: alternate_images: These have been merged into the main arch tree long ago. cfclient_sdl: I don't think has been updated in many years - I have a feeling daimonin probably has a more up to date version that should be examined if we're serious about this. client/gnome: hasn't been supported in a long time iso_arch: Like cfclient_sdl above - really not used since daimonin. maps: Been replaced by maps-bigworld. snip This seems like a good idea to me. Also, perhaps we shouldn't move CFJavaEditor, and instead use 'svn:externals' (See http://svnbook.red-bean.com/en/1.0/ch07s03.html) to link to Gridarta's copy of CFJavaEditor in their SVN repository. To do so would be something along the lines of this inside of a new empty CFJavaEditor svn repository: svn propset svn:externals 'https://svn.sourceforge.net/svnroot/gridarta/trunk/crossfire' . Which would effectively redirect svn clients to that url to download it if they would try something like a svn checkout https://svn.sourceforge.net/svnroot/crossfire/CFJavaeditor;. This makes sense to me because active CFJavaEditor development is happening in the Gridarta project, and if the old history is needed for historical reasons we have the cvs repository of it around. could do that. But then I wonder if that makes sense, or if whatever docs should just be updated to point to the gridarta repository. One reason here is developer permissions - if it is in the crossfire SVN root, people may expect that since they have crossfire SVN write permissions, they should be able to make updates to it - however, if it is a link, they won't. All that said, if CFJavaEditor has been superseded by gridarta, then it doesn't make sense to have a copy in the crossfire tree - so the question more becomes should a redirection be done, or just nothing at all? 4) I don't believe the SVN by default provides support for the $Id$ string version control at the top of files. I thik there may be modules that support it, but sourceforge is very particular in what modules they support (short list being ones that provide e-mail notification, and another that checkes file names for reasonable compliance). There may be client side scripts that could be used, but then that seems a little more problematic (some developers forget to use/install them, so their commits are not updated, etc). Does it just make sense to pull the $Id strings out of the files then? Well, the $Id strings have never seemed terribly useful to me (it was often more convenient for me to just check the timestamp of the build and/or source directory if I wanted to know when in CVS it was built from), however if anyone has any use for them, probably wouldn't be difficult to make a script to generate a .h file containing macros of that data, and put that in as part of the build system. The client had been modified at one point to provide that information, just to be more helpful in bug reports. That said, I agree that the header in each file probably isn't necessary. It might be nice to include the svn commit number in a header file, so that could be displayed, eg, the client could say something like: Crossfire Client 1.10 build 8963 Such that if a user reports a bug, we can easily check that global revision number and see if the bug may have been fixed, etc. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
