[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Anoncvs -> SVN
From:       Mickael Marchand <marchand () kde ! org>
Date:       2005-03-31 23:08:19
Message-ID: 424C82E3.4070502 () kde ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mikolaj Machowski a écrit :
| Dnia czwartek, 31 marca 2005 17:50, Thiago Macieira napisa³:
|
|>>4. Size of local repository (comparing to CVS)?
|>
|>Bigger to much bigger.
|>
|>The local extracted copy is twice the size.
|
|
| And in numbers?
| I forgot how big is clean unpacked CVS tarball :(
| tarballs of most modules are ca. 100M (without kdenonbeta and its
| descendants).
| Compiled repository is ca. 3G
|
|
|>>5. What happen if update will be suddenly interrupted, will be whole db
|>>  corrupted?
|>
|>Not sure. I don't know if we'll go with BDBFS or FSFS. If the latter,
|>the DB is just a bunch of mostly-text files. If we go with BDB, I'd
|>recommend running a recovery program after each update.

I think you are mixing different problems there.
whereas we use BDB or FSFS as no impact for the final user.
the working copy of users only has one format which has nothing to do
with BDB and FSFS
a _user_ will never have to run the db_recover and other svn admin tools.

if a svn up is interrupted, I think you can just start it over with
another svn up or eventually a svn cleanup to remove pending locks in
your working copy.

Cheers,
Mik

|
|
| Does recovery program require connection to repository?
|
| With CVS I was able to update my local copy once a week on dial-up. Not
| very stable connection but it worked very good. Will it be possible in
| the future?
|
| m.
|
|
|
|>>Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCTILgyOYzc4nQ8j0RAm6XAJ9gQicxDVL72iz2QLQ4g0ZEz+y2hQCZAShi
h6O5s/M1zJO45WXmZphw1DI=
=jFJw
-----END PGP SIGNATURE-----
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]