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
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
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,
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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:
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)
As noted in anothe e-mail, SVN won the vote for the source code system for
use
on crossfire.
Next step is to actually switch over. Looking on sourceforge docs, I notice
a
few things:
1) They don't have a conversion utility, but rather directions (using cvs2svn)
to make the change.
2)
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
25 matches
Mail list logo
