Announcement

Collapse
No announcement yet.

Need help with CVS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Great work ctplinuxfan

    That was just the information I had in mind when I wrote my post, you just did it much better

    Comment


    • #17
      Originally posted by ctplinuxfan
      PS: Sorry, if my english isn't so good or sounds a bit rough, i think i need a vocabulary upgrade...
      In that case you can use my dictionary to upgrade.

      -Martin
      Civ2 military advisor: "No complaints, Sir!"

      Comment


      • #18
        (Sorry for the delay, the birthday preparations kept me busy)


        You're English is just fine ctplinuxfan, don't worry about that (and it's better than my German at any rate )

        Thanks a ton for the info, that's an excellent overview.



        So, if you guys had complete and utter freedom to install whatever you wanted on Apolyton, what would you want to install? What would you regard the best option? I'm sensing a strongly preference for subversion (correct me if I'm wrong though), but what method of access would you prefer?
        Administrator of WePlayCiv -- Civ5 Info Centre | Forum | Gallery

        Comment


        • #19
          Happy birthday!

          I wasn't able to do anything either, my main harddisk screwed up and the os installation couldn't be recovered. Fortunately i had tons of data backups.

          Though cvs is a great version control and it's server installation is quite easy for the non-chroot scenarios, i'd prefer subversion.

          For the backups, cvs
          • uses text files to store revision-by-revision differences for each file managed by the repository
          • so it needs to be shutdown for backup purposes (else possible race condition: rewrite of a file or backup or partial backup of a begun commit)


          subversion otoh
          • stores files and their revisions in a berkeley db
          • accesses to the repository are transactions (db: ACID)
          • supports hot-backups using hot-backup.py or svnadmin hotcopy,
            i.e. backups are automatable e.g. in a mixed scenario: weekly full repository dumps using crond and incremental revision-by-revision dumps using hot-backup.py as a post-commit hook of the server


          It may be a good choice to make use of hot-backups, for the dumps are needed for server-upgrades anyway and subversion can automatically purge the pre transaction logs after the backup of a successful commit. O.k., the other reasons for backups are quite obvious.

          Despite that, subversion has the best cross platform support so far and subversion clients can access the server through http. It should also be possible to replicate apolyton.net accounts for subversion, for it uses apaches auth mechanism for authorization.

          For access methods, i would tend to setup an apache2 using mod_dav_svn (i.e. serve http and https only), for it should provide accessibility for anybody (if a proxy does not provide all needed extensions and nobody can be persuaded to add them, binding to a non-standard port like 81or using https should do the trick).

          Comment


          • #20
            I vote for subversion.
            the above reasons are enough but i would like to add that subversion most likely would have a lower impact on bandwith useage as it uses only the diff to commit a new revision as opposed to cvs that needs to transmit the entire file. well in real life the difference is probably very small so it should not be a decisive factor.

            any method of access would be fine for a client point of view, but it might be easyer to auth with apache using the existing user database to make sure that everyone has agreed to the license agreement.

            Comment


            • #21
              JFYI: subversion 1.1.0-rc1 is out. Even no dump was needed for update from 1.0.6.

              In short, renames backtracing has been fixed and the svn client has noticable speed improvements, and quite some bugfixes.

              The new fsfs fs-type however may not be an alternative to berkeley db, checkouts against HEAD require quite some time more, despite that server load would grow twice - oh - and its not tested that well, yet.

              Comment


              • #22
                Locutus: Any progress with this?

                Comment

                Working...
                X