Komodo with SubVersion

[komodo_aspn]

Hi All,

 

I'm not sure I can do what I'm thinking of doing...

 

After some previous disasters I now keep regular backups of all my work, every 5 minutes I backup any changed files from all of my projects, and every night I then take a complete backup. But over time this is taking a horrendous amount of space.

 

What I was thinking of doing is installing Subversion, or some other version control software, and using the inbuilt versioning so that I can monitor changes in files. I currently develop on Windows Vista using Komodo, all files are stored on my linux (CentOS) server, and all the projects (99%) are web based projects so I need Apache to also be running under the same environment. I work on websites for multiple clients, and these all run under seperate Apache VirtualHosts.

 

Is it possible for me to use Komodo / SubVersion / Apache in this way?

 

Is anyone using this type of setup? How difficult was it to setup?

 

Thanks in advance for any comments you can give me.

 

Regards,

 

Simon

_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[David Brewer]

It is definitely possible to do this, although this is really only
tangentially related to Komodo.  Where I work we do most of our work
on Ubuntu virtual machines, with all of our work checked into
subversion repositories.  The initial transition can be painful but
once you do it you'll wonder how you ever worked any other way.
Komodo will act as a client to your repository, but to be honest I
still prefer other clients such as TortoiseSVN (on Windows) or the
command line.

The most difficult part of setting up subversion for someone who is
new to it is choosing from the bewildering variety of ways to set up
such a system.  Subversion is a very flexible tool and gives you
plenty of opportunities to do things the wrong way.

I would recommend starting small to get a handle on the concepts and
then scaling up.  Doing some reading in advance will probably save you
a lot of time in the long run.

Some possibly useful books:
 * Pragmatic Version Control: Using Subversion by Mike Mason.  This
isn't a great reference book for the advanced user, but it is short
enough to be approachable as a good introduction to the subject.
 * Producing Open Source Software: How to Run a Successful Free
Software Project by Karl Fogel.  Not only about version control, but
has a great discussion of best practices for version control on open
source projects.  These ideas are applicable in other contexts as
well.
 * If you haven't found it already, http://svnbook.red-bean.com/ is a
good place for detailed information about Subversion.

The shop I work for does work for multiple clients as well.  For what
it's worth, here are some of the decisions we made:
 * We make a separate repository for each project.  Why?  So that if
necessary, we can archive an entire repository to recover its disk
space.
 * We access subversion through an Apache server, primarily to provide
external HTTPS access to the repositories.  This was possibly more
complicated to set up then the alternatives but works very well for
us.  We're actually using Apache on a Windows server for this purpose.
 * We're using FSFS rather than the Berkley DB backend.
 * Even with version control, you will still have your backup
issues... we do nightly backups of all the repositories.
 * We refrain from checking in large binary assets such as video or
photoshop files to the repository.  Subversion doesn't do a good job
of handling diffs to these files, which means that if you put these in
the repo it will swell in size dramatically.  There is no good way of
recovering this space if this happens, because deleting the file only
deletes it in the latest version of the repository.
 * Windows users use TortoiseSVN, which is an awesome SVN client for Windows.
 * We use the Trac issue-tracking system, which integrates with your
subversion repository to provide all kinds of neat information.

There's a whole new generation of version control software out there
which is probably technically superior to SVN.  But, especially if you
are primarily developing on Windows, SVN's ecosystem of related tools
like Tortoise and Trac is pretty hard to beat.

David

On Tue, Apr 29, 2008 at 11:10 AM,  <komodo_aspn@...> wrote:

>
>
> Hi All,
>
> I'm not sure I can do what I'm thinking of doing...
>
> After some previous disasters I now keep regular backups of all my work,
> every 5 minutes I backup any changed files from all of my projects, and
> every night I then take a complete backup. But over time this is taking a
> horrendous amount of space.
>
> What I was thinking of doing is installing Subversion, or some other version
> control software, and using the inbuilt versioning so that I can monitor
> changes in files. I currently develop on Windows Vista using Komodo, all
> files are stored on my linux (CentOS) server, and all the projects (99%) are
> web based projects so I need Apache to also be running under the same
> environment. I work on websites for multiple clients, and these all run
> under seperate Apache VirtualHosts.
>
> Is it possible for me to use Komodo / SubVersion / Apache in this way?
>
> Is anyone using this type of setup? How difficult was it to setup?
>
> Thanks in advance for any comments you can give me.
>
> Regards,
>
> Simon
> _______________________________________________
>  Komodo-discuss mailing list
>  Komodo-discuss@...
>  To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>  Other options:
> http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss
>
>

_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[Jeff Griffiths-2]

I agree generally with David, and have added some comments:

David Brewer wrote:
...
>  * We access subversion through an Apache server, primarily to provide
> external HTTPS access to the repositories.  This was possibly more
> complicated to set up then the alternatives but works very well for
> us.  We're actually using Apache on a Windows server for this purpose.

We use Apache and DAV/SVN as well, both internally and externally with
the Open Komodo repository. I also use it (a bit) on my own site. Setup
can be a bit tricky but if you have any questions let me know. I think
accessing SVN using https and a self-signed cert is realy handy. You can
even do tricks like allow read-only access to the world and restrict
write access to authenticated users.

>  * We're using FSFS rather than the Berkley DB backend.

@David: what is the advantage there?

>  * Even with version control, you will still have your backup
> issues... we do nightly backups of all the repositories.
>  * We refrain from checking in large binary assets such as video or
> photoshop files to the repository.  Subversion doesn't do a good job
> of handling diffs to these files, which means that if you put these in
> the repo it will swell in size dramatically.  There is no good way of
> recovering this space if this happens, because deleting the file only
> deletes it in the latest version of the repository.

+1, and this is where svn:ignore rules come in handy, without having to
do a bunch of fiddling with file systems.

As well, there is a great script included with the subversion source
package called 'svn-load-dirs.pl'. I use this tool to manage different
versions of external source trees; I originally came across it here:

http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion

JeffG




_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[komodo_aspn]

Thanks for both of your replies, I appreciate this is only "tangentially
related to komodo".
SubVersion is something I've never used, so any info you provided has been a
great help.

When using Komodo with Subversion, how does the checkout/checkin procedure
work, and when/how do we issue commit commands etc?

If anyone can help me off the komodo list with some of the server side
options I would appreciate it greatly. Particularly file access, I currently
use samba to access the files, but does this have to change when using
subversion with Komodo?

Simon
-----Original Message-----
From: Jeff Griffiths [mailto:jeffg@...]
Sent: 29 April 2008 21:23
To: David Brewer
Cc: komodo_aspn@...; komodo-discuss@...
Subject: Re: [Komodo-discuss] Komodo with SubVersion

I agree generally with David, and have added some comments:

David Brewer wrote:
...
>  * We access subversion through an Apache server, primarily to provide
> external HTTPS access to the repositories.  This was possibly more
> complicated to set up then the alternatives but works very well for
> us.  We're actually using Apache on a Windows server for this purpose.

We use Apache and DAV/SVN as well, both internally and externally with the
Open Komodo repository. I also use it (a bit) on my own site. Setup can be a
bit tricky but if you have any questions let me know. I think accessing SVN
using https and a self-signed cert is realy handy. You can even do tricks
like allow read-only access to the world and restrict write access to
authenticated users.

>  * We're using FSFS rather than the Berkley DB backend.

@David: what is the advantage there?

>  * Even with version control, you will still have your backup
> issues... we do nightly backups of all the repositories.
>  * We refrain from checking in large binary assets such as video or
> photoshop files to the repository.  Subversion doesn't do a good job
> of handling diffs to these files, which means that if you put these in
> the repo it will swell in size dramatically.  There is no good way of
> recovering this space if this happens, because deleting the file only
> deletes it in the latest version of the repository.

+1, and this is where svn:ignore rules come in handy, without having to
do a bunch of fiddling with file systems.

As well, there is a great script included with the subversion source
package called 'svn-load-dirs.pl'. I use this tool to manage different
versions of external source trees; I originally came across it here:

http://www.davidgrant.ca/maintaining_vendor_sources_with_subversion

JeffG


_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[David Brewer]

On Wed, Apr 30, 2008 at 2:17 AM, Simon Tiplady | Komodo
<komodo_aspn@...> wrote:
> Thanks for both of your replies, I appreciate this is only "tangentially
>  related to komodo".
>  SubVersion is something I've never used, so any info you provided has been a
>  great help.

No problem, glad to be helpful.

>  When using Komodo with Subversion, how does the checkout/checkin procedure
>  work, and when/how do we issue commit commands etc?

To be perfectly honest, I've found that Komodo works pretty well as a
client for checking in single files or quickly checking the diff
between two files, but not great as a client for large checkins or
other svn operations.  I've ended up sticking with TortoiseSVN in
Windows or the command line in Linux.  Maybe Jeff can shed some light
on the best way to use Komodo's svn integration.  :-)

>  If anyone can help me off the komodo list with some of the server side
>  options I would appreciate it greatly. Particularly file access, I currently
>  use samba to access the files, but does this have to change when using
>  subversion with Komodo?

I don't have time to go very in depth with this, but I can assure you
that you can still use samba to access the files.  A "working copy" --
files checked out from subversion -- is just a bunch of regular files
and can be worked on any way that you would normally access your
files.  Windows-based developers in our shop use TortoiseSVN over
samba to control their working copies on Ubuntu virtual machines all
the time.

David
_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[Shane Caraveo-2]

David Brewer wrote:

>>  When using Komodo with Subversion, how does the checkout/checkin procedure
>>  work, and when/how do we issue commit commands etc?
>
> To be perfectly honest, I've found that Komodo works pretty well as a
> client for checking in single files or quickly checking the diff
> between two files, but not great as a client for large checkins or
> other svn operations.  I've ended up sticking with TortoiseSVN in
> Windows or the command line in Linux.  Maybe Jeff can shed some light
> on the best way to use Komodo's svn integration.  :-)
>
>>  If anyone can help me off the komodo list with some of the server side
>>  options I would appreciate it greatly. Particularly file access, I currently
>>  use samba to access the files, but does this have to change when using
>>  subversion with Komodo?

We're trying to get 4.4 alpha 1 out, it will have a couple nice
additions for dealing with sets of files in SCC.

Regards,
Shane
_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[Trent Mick]

>>  * We're using FSFS rather than the Berkley DB backend.
>

Jeff Griffiths wrote:
> @David: what is the advantage there?

I believe it is less prone to getting wedged. Occassionally -- with
other Subversion releases anyway -- a Berkeley DB backend could get
stuck and you'd have to run some command on the server to get it
allowing commits again.

Not sure if those issues exist anymore with recent Subversion releases.
I believe the default backend in recent releases is FSFS.


Trent

--
Trent Mick
trentm at activestate.com
_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[Trent Mick]

Trent Mick wrote:
>>>  * We're using FSFS rather than the Berkley DB backend.
>
> Jeff Griffiths wrote:
>> @David: what is the advantage there?
>
> I believe it is less prone to getting wedged. Occassionally -- with
> other Subversion releases anyway -- a Berkeley DB backend could get

I meant:
...with *older* Subversion releases...


Trent

--
Trent Mick
trentm at activestate.com
_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss

[Michael Cartmell]

Subversion 1.4 has 'Support for BerkeleyDB 4.4 and its "auto recovery"
feature' making it much less prone to wedging. The advantage of fsfs is
that you can place the repository on a shared file system. DBD requires
a POSIX compliant file system.

See
http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.basics.backends 
for a full comparison.

Michael

Trent Mick wrote:

> Trent Mick wrote:
>>>>  * We're using FSFS rather than the Berkley DB backend.
>> Jeff Griffiths wrote:
>>> @David: what is the advantage there?
>> I believe it is less prone to getting wedged. Occassionally -- with
>> other Subversion releases anyway -- a Berkeley DB backend could get
>
> I meant:
> ...with *older* Subversion releases...
>
>
> Trent
>

_______________________________________________
Komodo-discuss mailing list
Komodo-discuss@...
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Other options: http://listserv.ActiveState.com/mailman/listinfo/Komodo-discuss