Uli,
On 7/8/2010 10:39 AM, Ulrich Eckhardt wrote:
>
> Other than that, what Les Mikesell said might be true, i.e. that you need to
> dump/reload your repository in order to reap the benefits of newer server
> versions.
>
Going to do a backup/dump/reload this weekend.
> There is one other w
On Thursday 08 July 2010, Cory Riddell wrote:
> On 7/8/2010 3:59 AM, Ulrich Eckhardt wrote:
> > Of course, the complexity (i.e. memory and time) for a merge operation
> > increases with the number of revisions and the number of files, but a
> > mere VS upgrade should only touch projectfiles and may
On 7/8/2010 7:41 AM, Les Mikesell wrote:
> Was the server upgraded from a pre-1.6 version without changing the
> repository?
No. It was created at version 1.6. All the data was imported from a
Visual SourceSafe repository.
Cory
On 7/8/2010 3:59 AM, Ulrich Eckhardt wrote:
>
> Of course, the complexity (i.e. memory and time) for a merge operation
> increases with the number of revisions and the number of files, but a mere VS
> upgrade should only touch projectfiles and maybe a few sourcefiles, all of
> which are easy to
Cory Riddell wrote:
Hi Uli,
Things have checked out and now we want to upgrade. I want to swap my
trunk and my branch.
This sounds strange now. Normally, you would merge the branch back into the
trunk. Also, what about the changes made to the trunk since you made the
branch? Do you want to dis
On Wednesday 07 July 2010, Cory Riddell wrote:
> My problem is that merges have been very problematic for me. They
> consistently fail due to running out of memory. I downloaded the
> 64-bit client tools from SlikSVN and they will work if it is the
> only thing running. My machine is a 4 core machi
On Tuesday 06 July 2010, Cory Riddell wrote:
> We are about to upgrade to a new Visual Studio. While preparing for the
> upgrade, I created a branch call VS2010 to test our software and make
> sure everything is working before moving everybody to the new IDE.
Completely normal approach, separate b
