[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Sourcesafe to SVN Conversion Questions

From: Scott Prugh <sprugh_at_telution.com>
Date: 2005-11-03 01:12:24 CET

Yes. Basically, developers will grab a full build from time to time
that is fully inetgerated across all teams. This is particularly useful
when trying to track down a bug on a newer build. A developer can just
grab the latest source and binaries and start debugging/developing. If
a problem is found, they can check out. A build is 100MB, but takes 6
hours to create. So the copy is cheap on a high-speed LAN, the building
is not.

So, it goes like this:

-Build machine gets current from SCM
-Build is executed and made available
-Developer grabs build
-Developer points SCM to root of build
-Developer starts checking out files

Of course in SVN, this doesn't work since all the .svn folders need to
be created.

So, I think we have two options:
1) What you suggested. Write a script that would pull down all current
binaries/debug symbols, etc from a current build. Have the developer do
the chekout once. This is interesting. I never thought of it that way.

2) Take the build with all the .svn directories. Will this work? Not
sure. I'm trying it right now.

Basically, we don't want the developer to have to rebuild because the
whole system is pretty large and the stuff they have to change is
minimal.

I did read the manual, but some of this didn't stick. Once I started
the transition, SVN became clearer. Perhaps I need to hit the manual
again.

Thanks for the input.

-Scott

-----Original Message-----
From: Nathan Kidd [mailto:nathan-svn@spicycrypto.ca]
Sent: Wednesday, November 02, 2005 5:59 PM
To: users@tortoisesvn.tigris.org
Cc: Scott Prugh
Subject: Re: Sourcesafe to SVN Conversion Questions

Scott Prugh wrote:

> -Set Working Folder
> Is there a way to swap in a delivered build so that TSVN recognizes
> the binding to the URL in subversion? Perhaps if I do a checkout on
> the build machine and deliver that whole directory? Any other way?

I'm not certain, from your description, exactly what you're trying to
do. Do you mean that your developers copy your output build tree, and
then checkout source into this same tree? Why not just reverse the
process: developers check out their tree once, and have a script they
can run that will copy in your build output?

> -Get Latest?
> Is there a GetLatest equivalent, or do I have to start with a clean
> directory each time? In other words, I can't seem to get files from
> SVN unless the target directory is completely empty. I get an error
otherwise.

The SVN equivalent to "Get Latest" is "Update", which works on an
already checked-out tree.
Export, will copy plain versions of files, but they cannot be commited
back to the repository.

It sounds like you'd benefit from reading the subversion book, and the
TortoiseSVN manual.

> -Global Properties
> What is the best way to set global properties like bugtraq:message and

> others? When I put them in the config file they do not seem to take
> effect. When I put them in the root of a repos branch they do not
> propogate to child folders. This may be because I am just getting the

> leaf and not all folders in between.

I think for a property to reflect down to a subdirectory you must have a
recursive checkout. TortoiseSVN couldn't magically connect sub
directories with a parent unless it was talking over the network (slow).

You may need to change the way you do some of your processes to complete
the transition svn, but having gone that road in our company I can say
it really is worth it in the end.

Cheers,

-Nathan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org

--
Received on Thu Nov 03 07:59:08 2005

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.