Raistmer, put your mod version of cuda sources to the our svn please ....

Did you put version I recived by E-mail before Berkeley's SVN was available in sinbad's rep already or there is no CUDA MB at all ?

Ok, don't think it's sources that crashed you PC, hope it's only binaries built from that sources
Sources pretty harmless
Will put what I have into CUDA branch.

Oops, and what is it ?
svn://sinbadsvn.dyndns.org/SaH_v6b/Cuda_app/seti_boinc
is it CUDA app indeed ?

With separate BOINC...
Maybe it's that sources I recived from Eric initially ?

LoL
"
Revision: 58
Author: jason
Date: 15:19:28, 13 декабря 2008 г.
Message:
Initial Berkeley Cuda app sources v6.05
----
"

Okay:

  - Checkout old cuda_app folder (fresh checkout)
  - go into folder, select all non-hidden, and rightclick-->TortoiseSVN-->Delete  (Not windows delete) ... They will disappear, but properly interacting with SVN.
  - Copy the replacement  files in using RightClick+Drag, On Release select "Copy & Add Files to This SVN WC" (or similar it says anyway)
  - Commit with nice friendly log describing exactly all the bugs and how to fix them, and all your girlfriends phone numbers.

Easy enough?

Not necessarily when done, we don't need to keep separate trees for that as they are sequential updates to the same project.  As you'd be effectively replacing the repository files with yours, no need to have 2 local copies when done either. You keep the repository version active for working on and archive/delete any other you're not working on.  The only need is for this in the repository.

Stockv6 cuda_app folder log would look like this:
  - First Revision = Berkeley 6.05 unmodified. (Obsolete but there for preservation)
  - Second revisiion = Berkeley 6.06 unmodified (Also obsoleted by your mods, but there if needed)
  - Third revision = Your 6.06

[Of course the revision numbers will be higher that 1,2 & 3, because of mixed in with Stockv6 non-cuda repository.]

So only one progressive Repository is needed but can fall back to any point later if you decide to, and could even create a branches subfolder if you later need two separate builds for some reason, but I can't see any need to do that,  unless you find your mods seriously went in the wrong direction, but even then that is better handled by reverting individual files.  Branching (which would make two separate lines to keep locallly) should only be needed if there are some reasons the builds need to develop in different directions then later hopefully find a way merge.  An example of this is the AK_v8 split off of SSE build because it broke SSE2+ speed.  Hopefully one day these become reintegrated.


 

There is one way to make it a bit easier that I'll go into further down, though, the easiest way I've found to accomplish this, like when AstroPulse needed to be updated to version 5 code from 4.35, is to drop the Berkeley files over an already committed working copy.  All changes then show in "Check for Modifications" which you can then do the Ping-Pong merge game on a per file basis, to decide which changes are relevant to your build.

The other way would be to use the SVN 'Externals' feature.  Look up 'external repositories' in the TortoiseSVN help.  Basically it should allow you to grab different subfolders (say one named 'Berkeley') which would sync to Berkeley whenever you do an update, then you can use regular merge tools like 'Two-Tree-merge' to grab the changes you want.

Up to you which approach to use. Just avoid committing until you have it arranged the way you want, but commit before you try merging new code in from Berkeley and you should be alright.  Either way it is still some juggling, though both are effective.  My only aversion to Method #2 is that updates of the repository rely on two servers being operational at the same time.