Windows SVN -- Tortoise?

[Lost User]

PCSpectra wrote:

Possible using SVN/Tortoise? What command would I be looking at? import? merge?

Either I dont basically understand your question or the command you're looking for is svn update :)

[alex barylski]

EDIT | I might be able to use svn import for each backup...is this right? EDIT 2 | "After importing data, note that the original tree is not under version control. To start working, you still need to svn checkout a fresh working copy of the tree." I was afraid of something like that. :( Ideally I want to do something like that just a little backwards I think... The SVN is installed on my Windows computer...the code is stored on a Debian server, which does not have SVN and likely never will. I develop in real time on this Debian server and make backups daily before I call it quits. I want the Windows desktop to have SVN installed as well as Tortoise, so that I may simply drag the latest version onto a directory and have my latest changes merged with the previous version. So in a sense...the working copy is the Debian server and the repo is the Windows desktop. How do I use update when the Debian server doesn't have SVN installed. More importantly, because my code is quite modular, when I refactor, it often means changing file names, directories, etc. Adding new files, removing old files, etc. This is the main motivation to just back up a copy at days end. I used SVN on my Windows machine before but I believe I had to create files/folders and manually commit each change, then re-upload files back to the debian server. PITA. The problem seems simple enough: 1. Make a backup of an entire source tree at end of day on my Windows machine. 2. Once backup is finished downloading merge the source tree with a previous one stored on Windows desktop Again, my Windows machine has SVN installed but the live code (where all the changes happen) is not on the Windows machine, it's on a Debian machine. Do I just download the source tree from Debian onto my Windows desktop, then using Windows svn update:

svn update brings changes from the repository into your working copy

I think I want to bring the changes from the working copy into the repository... :confused:

Blog Entry: 7 Software development best practices to make you more effective and productive PCSpectra :: Professional, Affordable PHP Programming, Web Development and Documentation

[El Corazon]

svn updates/commits what has changed and merges what others have changed back in. Even with just you, you can have multiple boxes, change something on one and update (get it) on another and merge if you have changed the same file. Commit sends the updates to the machine. I suggest you take the training at the tortoise svn site. Learn what you have rather than just ask about it. It sounds like you know very little about what you have. and in this case because of the power in SVN a little knowledge could be a dangerous thing.

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."

[alex barylski]

El Corazon wrote:

It sounds like you know very little about what you have

Heh?

El Corazon wrote:

and in this case because of the power in SVN a little knowledge could be a dangerous thing.

Dangerous in what way? It's not like I'm going to open up my source to security holes because I started using verison control. As for it being complicated? From what I remember, it took me less than a day to read the first 5-6 chapters of SVN book, but like anything, if you don't use it, you loose it. I understand how SVN works with a developer team, but as a lone developer with a slightly backwards setup, I'm not sure the team best practices apply. But what would I know about my own development practices. :P Cheers, Alex

Blog Entry: 7 Software development best practices to make you more effective and productive PCSpectra :: Professional, Affordable PHP Programming, Web Development and Documentation

[Johnny]

I may also be misunderstanding what you've said but it sure sounds like you're not using SVN properly. You should be able to work on your latest version and simply commit the changes into the main repository - no need for manual backups at the end of the night followed by a merge.

PCSpectra wrote:

I think I want to bring the changes from the working copy into the repository

That would be svn commit. If you are storing your code on a Windows machine but developing on Debian then you will need SVN installed on Debian (but not necessarily Windows). If you don't then you will create an awful lot of extra work. The workflow should be fairly simple: Edit code on Debian machine svn commit code from Debian machine to Windows That's it. No manual merges, no manual copies or backups.

[alex barylski]

Johnny ² wrote:

I may also be misunderstanding what you've said but it sure sounds like you're not using SVN properly.

Thats because I'm no* using SVN :P

Johnny ² wrote:

You should be able to work on your latest version and simply commit the changes into the main repository - no need for manual backups at the end of the night followed by a merge.

If I understand correctly...everytime I add a file or directory or move it...I need to notify SVN??? This would be a serious PITA as my files are constantly moving to better reflect their purpose, etc. I maintain backups because now all I have to worry about is backing up at days end. All files/folders and their changes stored in one fell swoop. The problem (which isnt' really a problem only storing diff's would be more efficient) is that having multiple backups is space consuming. Ideally I would write a custom script which take my latest source tree and DIFF it against the previous source tree and store only the DIFF, instead of two individual source trees. I know this can be done using SVN but their process is slightly backwards to the process I am used to, which normally wouldn't be an issue, but because I cannot install SVN on a shared host, which is where I store the code which is actively developed and updated, I need to make backups to my Windows machine. I know I could install SVN on my Windows machine but then everyday I would have to check out a working copy, upload it to the debian server, and each time I added a file or directory I would have to notify SVN on my Windows machine. See the problem with using SVN as it's intended for this situation? The wonders of remote development. :) So what I was thinking (not doing -- which is why I asked to see if someone could shed light on the subject for me) is that when I perform my nightly backups, instead of storing YET ANOTHER copy of the source tree (modified) I would "import" the latest source tree into the repo and hopefully have SVN manage merging updates. However, it seems "import" will not handle merges/updates whatever...seems I need to check out a working copy and then mergse those changes from the working copy. So my working copy, is not a working copy in SVN sense (I don't blieve -- is it?) it's just a source tree stored on a shared host. SVN repo is (would be) on my Windows machine but I do not develop on my Windows machine, outside of accessing files from the

[alex barylski]

Johnny ² wrote:

If you are storing your code on a Windows machine but developing on Debian then you will need SVN installed on Debian (but not necessarily Windows). If you don't then you will create an awful lot of extra work. The workflow should be fairly simple:

I see what your saying but... My Debian server does not have SVN installed so... Ideally I wanted the backups to essentially be versioned using SVN...Not taking out a working copy at each days end for backup purposes, if this is what you meant???

Blog Entry: 7 Software development best practices to make you more effective and productive PCSpectra :: Professional, Affordable PHP Programming, Web Development and Documentation

[Stuart Dootson]

You've identified the right tool for the job, but...

PCSpectra wrote:

Ideally I would simply click ajd drag my latest source tree onto a special folder and the merger would happen automagically...

SVN doesn't quite work like that - it's *not* a backup system. The best way to work with Subversion is:

1. Set up a repository on the Debian server, preferably with standard root folders of 'tags', 'branches' and 'trunk'.
2. Use Tortoises 'SVN Checkout' command to link a folder on your development machine to the repositories 'trunk' folder. I'd suggest not using your current development folder for this, 'cause it can get messy.
3. Next, copy your current development folder's contents into the folder you linked to the SVN repository. Next, you'll need to tell SVN (using Tortoise) which files should be added to the repository (uisng Tortoise's 'Add...' command) and which should be left out and not controlled (using Tortoise's 'Ignore' command). In general, you want to ignore anything that's a product of the build process (like object code files, executables etc) and add things like source code, project files etc. Other things to ignore are .suo files, .csproj.user files and (if you're using C++) .ncb files.
4. OK, you're ready to develop!!!! Open your solution *from the directory linked to the SVN repository*, not where it was originally.
5. When you want to store everything to the repository, apply Tortoise's 'SVN Commit' command to the root folder that you originally connected to the SVN repository. This should pop up a dialog showing all the files that have changes. You can double-click on files to see details of the file changes and select which files (usually all) you do want to synchronise with SVN.

As you can see, the 'automagic' folder you talk about should be your development folder. Also, <i>you</i> have to initiate the merge with the Subversion repository - it doesn't happen automatically. HTH!!!

[Member 96]

No, he's right you do need to learn more about subversion works, your questions clearly indicate you don't. It's not dangerous now, but it can be dangerous after you've been using it for a while and come to rely on it. It's not rocket science but it isn't at all anything like an ordinary backup or file operations and you need to get your head around that first. I used to backup similar to what you do as a single developer I thought there was no need for version control, I was entirely wrong about that, it's extremely useful for far more than just backing up files. What I suggest is that you look at mirroring the repository specifically for the problem you want to alleviate. I'll give you an example: we have a remote server we rent from ServerBeach in Los Angeles, I'm in Canada on the west coast on a small lan with a file server. When I make a code change or add a file or remove a file from my project and it's been enough work that I don't want to lose what I've done, or I need to step away from the computer for any reason, I make a commit from tortoise of the folder my project is in, an automatic process is triggered where my changes are stored in my local server's repository, it then immediately and automatically sends those changes to the remote server in Los Angeles. Since this goes on throughout the day and is small amounts of data it's very fast. Aside from all the benefits of version control this also gives me a pretty reliable backup in addition to the nightly tape backups on our local server and the nightly remote backups on the LA server to a separate FTP server on ServerBeach's own network. So what you might want to consider is creating a repository *on* the remote Debian server you work on, also create a repository on your local windows computer. Make the local repository a mirror of the remote repository. Make sure you setup your firewall to only allow subversion connections on the port it uses from each other's IP address so that there is no possibility of someone stealing your code (unless it's all open source anyway but you still don't want people messing with the code without you being aware of it.) As you work throughout the day any changes you make and commit on the remote debian server will be mirrored automatically to your local windows machine. Because you are doing it incrementally throughout the day and it's only a few kb here and there it's very fast and you are always in sync at both ends. At the end of the day there is *no* backup to make, it's not nece

[caspianx67]

I'm probably doing it wrong, but here's the scenario that works for me. I have two production web servers in a cluster, one development server, and one test server. I develop ColdFusion apps (yeah, I know, this is mostly a MS forum, but CF is what we've got here) on dev, commit changes as I complete them, update test and test them, then update both nodes of the production cluster to deploy releases.

1. Decide on which directory is going to be my baseline for the code I want in source control.
2. Create a repository directory where I want my "backup" to be.
3. Do my initial load of files to the repository using TortoiseSVN. I did this a long time ago, and haven't done it much since, but I think it's the Add option.
4. Move my directory of files to a safe place temporarily.
5. Create a new directory and point it at the repository then use the TortoiseSVN update to "check out" the files I added.
6. Satisfy my ingrained sense of paranoia and diff my backup directory against the directory I just updated to make sure everything is present and accounted for.
7. Do the same thing on test and production -- updating empty directories with the code I had committed.
8. It's pretty much safe to delete the backup directory now

I don't know how to make use of the whole trunk and branch thing, so I have to make sure I commit my changes serially. Since I'm the only developer, this isn't generally a problem. I build stuff on dev, and when I get some block of new functionality completed, I commit all the changes related to that function at once, then update test and bring in other folks to QA. If everything tests fine, I update both production nodes afterward. I used to use WinDiff to compare directories and laboriously move each changed file manually, but TortoiseSVN has made that practically obsolete. NOTE: I do NOT have a SVN server installed anywhere. TortoiseSVN can write directly to a SVN file system without needing the server piece. -matt

Matt Newby President, Matt Newby Enterprises, Inc. matt@mattnewby.com