ExpressionEngine CMS
Open, Free, Amazing

Thread

This is an archived forum and the content is probably no longer relevant, but is provided here for posterity.

The active forums are here.

Version Control System

September 27, 2007 12:32am

Subscribe [10]
  • #16 / Sep 29, 2007 7:08am

    Michael Wales

    2070 posts

    Code Arachnid:
    This is a lot like the setup I was referring to. You mentioned having a dev site - where only developers can view the site. Is this automatically built based off of the commits to the SVN repo? How did you go about accomplishing this?

    I would love to have an SVN repo, each developer would have a local copy they would work off of, and a (nightly?) build that is automatically pushed to a server in which developers can view their work in a replicate of the production environment.

  • #17 / Sep 29, 2007 7:34am

    Code Arachn!d

    92 posts

    @walesmd

    Due to the nature of our specific development - we considered having developer independent builds. The place I was at previously did this - and it was frustrating for our developers because they often worked on the same project with pieces that related to each other - so versioning went to the dogs so to speak because the developer couldn’t see progress from the other developers builds until it was checked in…

    This was solved currently by keeping a “dev” repository - this way via the DNS what everyone is working can be seen together - we’re a small enough shop that we don’t have to worry about cross over in the same file at the same time (this is largely avoided by communication and good project management). Ideally it would be that each developer had their own repo and then they pushed to the dev environment - but that kind of got ditched just due to the logistics of it running - without headache to the dev team.

    This is how we have the drive organized.

    /Site Drive
      /domainname
        /dev
        /stage

    thus when browsing http://domainname-dev points to the dev folder and http://domainname-stage points at the stage folder.

  • #18 / Sep 29, 2007 7:39am

    Code Arachn!d

    92 posts

    One thing I should also note about our environment - we set it up this way so that the files themselves are housed in our backup routine - this way if a server crashes - it won’t affect our code - and since they are on a raid setup it’s pretty smooth sailing if something goes down with the sites drive.

    One thing we haven’t really fixed yet - is the pathing and dbase connectivity between dev/stage/production because obviously you don’t want to overwrite your config files on the production environment. This is one reason why I’m working on a method (it’s already roughed in - just not to the level I’m satisfied yet), that will call the config vars in from the database - I’m assuming this will probably add a little overhead - but the benefit is that I can keep my data sources separate a lot easier than I can my config files - so adding a config would be as simple as promoting a sql query… this way the only file I have to worry about is the database connection file and that should be pretty easy to make so that it’s a manual push between the environments - if anyone has a better idea - I’m all game


    < /hijack of this great thread on svn >

  • #19 / Sep 29, 2007 8:36am

    Delian Angelov

    9 posts

    This is one reason why I’m working on a method (it’s already roughed in - just not to the level I’m satisfied yet), that will call the config vars in from the database - I’m assuming this will probably add a little overhead - but the benefit is that I can keep my data sources separate a lot easier than I can my config files - so adding a config would be as simple as promoting a sql query…

    @Code Arachn!d
      I am not sure that I understood you well, please can you elaborate about this configuration comming from a database ?
    Do you mean that all environment specific information is keeped in a DB table, so that you issue the same SQL queries to retrieve it from each DB ?

      I think that is a very interesting idea ... thanks for sharing it !

      The way we do this now is by having separate config files (config_DEVT.php config_PROD.php and config_TEST.php), which are all version controlled and are located in the same folder, and an unversioned symbolic link (config.php) in the same folder. The symbolic link points to the correct file in each environment.

      I can definitely see some advantages in your approach, because then the code base can be absolutely the same in each environment, and the only difference will come from the DB, where you have it anyway, because of the different dev/test/prod data. It will probably require separate machines for the different setups, so that they can use the same settings for the SQL connections, but that can be achieved easily with some kind of virtualization, even if someone does not have the physical hardware.

  • #20 / Sep 29, 2007 2:22pm

    Code Arachn!d

    92 posts

    @Delian

    Exactly - I looked at doing a similar approach you are using right now - the only thing holding me back is the use of multiple config files already. I’m not opposed to config files - I just think they get cumbersome after a while (especially since I tend to make sure they have anything that might get abstracted out - for ease of config later on and other sites…)

    I wrote an extension to the CI_Config class a little while ago - and am working on pimping it up a little more before I roll it into a production site. You can see the rough version here: Config Class Extend to Database

    Again I’m not trying hijack this thread over config files - but I think they do come up especially version control and promoting code between different environments.

  • #21 / Sep 29, 2007 5:08pm

    llbbl

    324 posts

    On Windows you could just grab TortoiseSVN and wherever you want that repo to be, create a new folder. Right click -> TortoiseSVN -> Create Repositry here.

    Anyone know a good SVN client for Mac OS X?

    Textmate has built-in SVN capabilities.
    http://macromates.com/textmate/manual/bundles#subversion

    There are a couple other options…

    svnx
    http://www.lachoseinteractive.net/en/community/subversion/svnx/features/

    installing
    http://www.wikihow.com/Install-Subversion-on-Mac-OS-X

    xcode
    http://developer.apple.com/tools/subversionxcode.html

    svn client from tigris
    http://metissian.com/projects/macosx/subversion/

    finder integration
    http://scplugin.tigris.org/

  • #22 / Oct 02, 2007 7:22pm

    Kevin Kaske

    9 posts

    There are some free subversion hosts out there if you want to try subversion out and not get your hands dirty. http://www.assembla.com/ is the one that I’m using. They have lots of great tools for development teams. I’m sure there are some others out there…. Assembla is just the best I have found so far.

  • #23 / Oct 03, 2007 4:51am

    wildcard99

    13 posts

    but would it still be practical to use subversion even if i just want to have an automatic backup of my files?

    coz i often mess with them.

  • #24 / Oct 03, 2007 6:30am

    Luci3n

    22 posts

    I use a slightly different setup where our developers have a normal repository each having their local working copy and on the live server we have a live repos which when updated automatically updates the site using subversion hooks.  This way we can have demo.domain.com, http://www.domain.com separate but also available to the client to view and verify the changes before they will happen.  Then once the the changes are verified they are committed to the production repository which automatically updates the live site.  So basically we have three repositories production, demo, and inhouse two of which are based online and one inhouse.  The updates any updates are easy to manage with minimum time for updates to the demo and production server.

    The client we tend to use is RapidSvn as this is platform independent but does not have create repository or diff tools.  Depending on the developers platform they can choose the diff tool they prefer which integrates nicely with RapidSvn.

    http://rapidsvn.tigris.org/

  • #25 / Oct 03, 2007 6:30am

    Delian Angelov

    9 posts

    @wildcard99
    In my opinion, it IS a VERY practical thing to use a version control system for *any* kind of development. The benefits that a version control system gives you are much more than simple backups - you get logs on when and why you changed something, diffs between versions, easy collaboration with someone should the project becomes something more than a one man solution/experiment. You will thank yourself for having the foresight to use a VC in only a week or so 😊.
    That said, if you have not messed up with subversion before, I would not recommend it to you.

    The overhead of this particular VC system is too high when you develop alone and want to just test a little hack. This is because you need a sysadmin that have alreade set up a Subversion repository somewhere. There are many things that can go wrong if you do not have the experience to do it. Especially if you are new and still unexperienced with the process.

    In case you still want to go this way - you can try this http://lifehacker.com/software/subversion/hack-attack-how-to-set-up-a-personal-home-subversion-server-188582.php (it is a reasonably short and tested way to setup a private subversion repository server under windows), or try this http://www.howtoforge.com/debian_subversion_websvn if you are a debian linux user. There are also free SVN repositories online, but you will have to had a really fast connection, since SVN contacts the central repository for most history related operations (svn log and so on).

    Since the title of the thread is “Version Control System” and not just “The subversion VCS” 😉, here goes a little personal rant - for 6 months I’ve been a commited and happy GIT user 😊 .  It is much better than SVN at many things :
    1) sheer SPEED, because you have a local repository and you use it for 90%-100% of GIT operations
    2) support for easy last commit ammending : if you happen to change your mind about what goes in the last commit that you made (it is amazing how many times this little feature is useful) - this allows you to have better commit changeset and description messages, so the log of the changes becomes more useful ...
    3) GIT has support for distributed development with much better merging and conflict resolution than SVN ever had, so it will scale better when/if you decide to have several people work on your project.


    The only drawback so far is that (at least for now), there is not a client comparable with the nice integration of TortoiseSVN for Windows (well, may be I do not know if such a beast exists, please, correct me if it does).

    That said, the GIT’s command line integration is much better than subversion’s, and the commands that you need in your typical development scenario are few:
    “git init” at your project root to setup the GIT repo.
    “git add FILE/FOLDER” to add a changed folder to GIT knowledge.
    “git commit -m ‘Description of the change’” to commit your changes.
    “git checkout HEAD” to revert changes to the last commit, HEAD^ will revert the last commit, HEAD^^ will revert the last 2 commits and so on.
    “git log” to see a log of the changes so far.
    “git status” to see the status of your project from GIT perspective - what has been changed but still not commited, what is still not version controlled and so on.

    Basically, these commands are used 95% of the time, and picking up the rest is very easy since there is extensive console and online documentation, with common use cases and so on.

  • #26 / Oct 03, 2007 6:36am

    Luci3n

    22 posts

    I’ve never tried GIT but I’ve heard good things about it are there any good gui clients similar top tortouseSVN or RapidSVN?

    If someone is looking for a setup for Apache2 with SSL on Ubuntu:

    http://www.sellersrank.com/ubuntu/setup-apache-subversion-ssl-https-with-virtual-hosts-on-ubuntu/

  • #27 / Oct 03, 2007 6:42am

    Delian Angelov

    9 posts

    The only GUI client I have used so far is gitk that is TCL based one (and looks somewhat ugly^H^H^H^Hfunny) - it comes with git itself. I have no doubt that it will have a better one, when it becomes more popular - it may be even already have, but I have not bothered to check, since I am comfortable with the console commands.

  • #28 / Oct 03, 2007 6:55am

    Delian Angelov

    9 posts

    Hm, there is a list of GUI clients on the GIT’s wiki page, check it out at
    http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-cee25e252efc24b245482fe9fa8d24ff5d5af1d6

  • #29 / Oct 03, 2007 7:36am

    Delian Angelov

    9 posts

    I’ve just tried qgit - it looks very nice so far, and there are implemented some highly informative views of my current project’s GIT repository and they are really snappy fast (just as git itself) ... there are keyboard shortcuts for the things I tried, so it is really comfortable to navigate it.
    It is a standalone program - so I guess I will just leave it running in a virtual workspace desktop while I work, and when I’m done will simply switch to it to commit changes, see progress, etc 😊 .

    Unfortunately, I do not think there is a windows version of it though, because it says it uses QT 3.x, which is not ported to windows. Probably in future it will migrate to QT 4, which has a windows port, so it will be available to windows users too.

  • #30 / Oct 03, 2007 3:44pm

    llbbl

    324 posts

    but would it still be practical to use subversion even if i just want to have an automatic backup of my files?

    coz i often mess with them.

    It is really helpful when there are more than one person working on the code. I still prefer to use ftp if I am the only one coding.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases