You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "McDonnell, David" <dm...@csu.edu.au> on 2003/08/22 01:34:23 UTC
Source migration
Hi all,
We're looking at implementing a source control system in my
organisation, and subversion is looking like an excellent candidate. The
one wall I have hit is in relation to source migration. We have 3
seperate environments: devel, qa and production. Our current in-house
written system is a source versioning system as well as a migration
utility (eg a developer can migrate a file to qa or production from the
command line).
I know subversion does not do this automatically, but it looks like this
could be implemented on top of the system. I was envisaging a project
layout like this:
/project/trunk/
-> main development line
/project/migration/
/qa/ - qa branch that is checked out to qa enviroment
/prod/ - prod branch checked out to production
And to migrate a file you would just "svn copy" it from /project/trunk
to /project/migration/qa/ or /project/migration/prod/ depending on where
you wanted to migrate it to. To achieve this a "svn checkout" process
would need to run regularly on each box to get the latest version of its
migration branch (prod or qa).
Now before I reinvent the wheel, :) does anyone have any experience they
would like to share on migration? Has anyone used subversion to do this,
or used something else with subversion to get the same result?
Cheers,
Dave
======================
Dave McDonnell
WWW Programmer
Online Services
+61 2 69334217
david.mcdonnell@csu.edu.au
======================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnversion & svn st
Posted by Bill Comisky <bc...@pobox.com>.
On Fri, 22 Aug 2003, Ben Collins-Sussman wrote:
> Bill Comisky <bc...@pobox.com> writes:
>
> > I noticed that when I run 'svnversion' and 'svn st' it will take a "long"
> > time (~12s on /svn source tree) to execute,
>
> Yes. Every single working file in your working copy needs to be stat()ted.
>
> > and then after the first execution it will run quickly (< 1s).
>
> And now your OS disk-caching kicks in. :-)
Hadn't thought of the caching as the reason for the speed up. Especially
since the slowdown seems so regular (overnight). I was assuming some cron
job was changing my directory access times and making svnversion/svn st do
more work. As a test I just ran 'hdparm -f' on my filesystem to flush the
cache, then 'time svnversion .' twice.
1st run after flush: 2.56s elapsed
2nd run after flush: .40s elapsed
1st run every morning: ~10-12s elapsed.
Maybe there is some other caching somewhere I'm missing to make up the
difference? Regardless, I think I'll just setup a cron job to run it
early in the morning!
thanks,
bill
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnversion & svn st
Posted by Ben Collins-Sussman <su...@collab.net>.
Bill Comisky <bc...@pobox.com> writes:
> I noticed that when I run 'svnversion' and 'svn st' it will take a "long"
> time (~12s on /svn source tree) to execute,
Yes. Every single working file in your working copy needs to be stat()ted.
> and then after the first execution it will run quickly (< 1s).
And now your OS disk-caching kicks in. :-)
> I just did a 'find . -ctime -2', 'find . -mtime -2', and 'find -atime -2'
> at the root of the tree. ctime (status last changed) and mtime (last
> modified) showed nothing for the last 2 days. atime (last accessed)
> showed all of the contents of the .svn subdirectories and all of the
> directories. I did just run 'svn st', so that makes sense. So what do
> 'svnversion' and 'svn st' use as an indicator to recheck the directory
> contents?
I'm not sure I understand your question. Subversion uses an algorithm
similar to CVS to determine if a file has been modified or not:
* if the timestamp hasn't changed ==> no change
* else if filesize of working & base files aren't equal ==> changed
* else, do a byte-for-byte comparison
> This is probably a non-issue for most, but I call svnversion from my
> (non-compiled) code to get the revision # for my single-revision working
> copy. So the first time I do that every day I have to wait an agonizing
> >10s (which is an hour a year I'd rather do something else with ;)
svnversion is basically doing the same thing, but on directories: it
loads up the .svn/entries file of every single directory in order to
"collate" all the working revisions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
svnversion & svn st
Posted by Bill Comisky <bc...@pobox.com>.
I noticed that when I run 'svnversion' and 'svn st' it will take a "long"
time (~12s on /svn source tree) to execute, and then after the first
execution it will run quickly (< 1s). Then I noticed this behaviour every
day, even though I hadn't accessed the directory tree in question. Or
hadn't accessed it directly anyway... My best guess is a backup script or
updatedb cron job is accessing the directories.
I just did a 'find . -ctime -2', 'find . -mtime -2', and 'find -atime -2'
at the root of the tree. ctime (status last changed) and mtime (last
modified) showed nothing for the last 2 days. atime (last accessed)
showed all of the contents of the .svn subdirectories and all of the
directories. I did just run 'svn st', so that makes sense. So what do
'svnversion' and 'svn st' use as an indicator to recheck the directory
contents?
This is probably a non-issue for most, but I call svnversion from my
(non-compiled) code to get the revision # for my single-revision working
copy. So the first time I do that every day I have to wait an agonizing
>10s (which is an hour a year I'd rather do something else with ;)
bill
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Source migration
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
Hello David,
No need to keep checked out working copies. SVN is able to do
server-side copies. Since you say you are migrating files, this is even
easier...
See "svn copy --help" or the book at http://svnbook.red-bean.com/ for
more information.
Hope that helps !
François
On Fri, 22 Aug 2003 11:34:23 +1000, "McDonnell, David"
<dm...@csu.edu.au> said:
> Hi all,
>
> We're looking at implementing a source control system in my
> organisation, and subversion is looking like an excellent candidate. The
> one wall I have hit is in relation to source migration. We have 3
> seperate environments: devel, qa and production. Our current in-house
> written system is a source versioning system as well as a migration
> utility (eg a developer can migrate a file to qa or production from the
> command line).
>
> I know subversion does not do this automatically, but it looks like this
> could be implemented on top of the system. I was envisaging a project
> layout like this:
> /project/trunk/
> -> main development line
> /project/migration/
> /qa/ - qa branch that is checked out to qa enviroment
> /prod/ - prod branch checked out to production
>
> And to migrate a file you would just "svn copy" it from /project/trunk
> to /project/migration/qa/ or /project/migration/prod/ depending on where
> you wanted to migrate it to. To achieve this a "svn checkout" process
> would need to run regularly on each box to get the latest version of its
> migration branch (prod or qa).
>
> Now before I reinvent the wheel, :) does anyone have any experience they
> would like to share on migration? Has anyone used subversion to do this,
> or used something else with subversion to get the same result?
>
> Cheers,
> Dave
>
> ======================
> Dave McDonnell
> WWW Programmer
> Online Services
> +61 2 69334217
> david.mcdonnell@csu.edu.au
> ======================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Source migration
Posted by Ben Collins-Sussman <su...@collab.net>.
"McDonnell, David" <dm...@csu.edu.au> writes:
> /project/trunk/
> -> main development line
> /project/migration/
> /qa/ - qa branch that is checked out to qa enviroment
> /prod/ - prod branch checked out to production
>
> And to migrate a file you would just "svn copy" it from /project/trunk
> to /project/migration/qa/ or /project/migration/prod/ depending on where
> you wanted to migrate it to.
I'm not sure why you need to explicitly copy things.
Your process sounds odd to me -- is it really individual *files* that
get promoted from one branch to another? Or is it *changesets* that
get promoted? The latter is the more common case.
For example, someone fixes a bug in the devel branch. The change is
then 'ported' (via 'svn merge') to the qa branch for testing. If
it's all good, the change is then applied to the production branch.
So if that's what you're talking about, this is just a matter of doing
merges from branch to branch. Very common stuff.
If you're really talking individual file promotion, then yeah, sure, I
guess you can manually copy them around. As Francois said, you can
just run 'svn copy URL1 URL2.' No need for working copies. But this
case seems odd to me. Version control is usually about managing sets
of changes, not about juggling individual files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org