tortoiseSVN

[wiebe@CARYA]

If the files are in the repo, you should see the green 'v' icons on each file and folder.

If you don't see those icon overlays, something is wrong.

If all's well, simply open the files from the repo, and change them. The icons should turn to red "x" for the files you've changed, or the folders that have changed files.

---

@metzler wrote:

make a working copy of the files in another folder, change those, and then add and commit them to the repo?

If so, do I then delete the working copy?

---

You can do that, but it won't be very practical.

Note that the folder is not the repo. It's a checkout of the repo. The files are kept in a 'database' (the 'repo'), and you can't (conceptually) change them once they are committed. Each new commit will change the head or branch in the repo, keeping the previous version. In fact, only the changes are stored.

[metzler]

I have been changing the files in the folder, and then seeing the red x on them.  I then commit them and the x turns to a green v. 

Since the folder is not actually the repo, sounds like I have been doing it the right way.

Thanks.

[wiebe@CARYA]

---

@metzler wrote:

I have been changing the files in the folder, and then seeing the red x on them.  I then commit them and the x turns to a green v. 

Since the folder is not actually the repo, sounds like I have been doing it the right way.

Thanks.

---

That's spot on. Changed files turn red, until you commit.

Careful though! If you revert to a previous revision (an old state of the code) you will still get green icons. Green icons tell you the files did not change compared to the revision that was checked out.

This also means that when someone else changes the code (or you changed the code from some other location) the icons stay green. The files did not change compared to the revision you checked out, so that is correct. But confusing. It does not signal the changes between the latest commit, but the changes to the revision that was used. This is handled good though. When you commit the changes, and other changes where committed, SVN will notice, and you can get conflicts that will need to be resolved.

It's not that hard once you get the model right.

[billko]

The only issue I have with versioning software is not actually with the software; it's that if you even have one person who doesn't know what they are doing, it can cause headaches forever.

[Bob_Schor]

An important aspect of Version Control is the Repository.  This has the "crown jewels", a "safe" version of your code, and all its previous incarnations and iterations.  Ideally, it should not be on your PC, but rather on a Server "somewhere" (most are "out there on the 'net") where they are being constantly backed up and protected against data loss.  It is not the same thing as having "another copy" on your PC somewhere!

@Gregory posted a link to a tutorial by Fabiola de la Cueva on TortoiseSVN, using a Toolkit from Viewpoint that helps with some of the trickier steps (setting up the initial Repository).  One minor complaint (from me) is that she seems to be using (as the location of the Repository) a Network Drive instead of an external Server, but I trust that this drive is being "protected" by being properly protected from data loss.

Here is a simplified description of using SVN:

• SVN works on a "Client/Server" model.  Your machine, where you do Development and use Projects saved in SVN Repositories, is the "client", while the machine that houses (and manages) the Repositories, and typically is a separate Computer, is the "Server".  Note it is possible to have the Client and Server be the same machine, but I strongly advise against this.
• You should think in terms of "Projects", and having a Repository for every Project.  The most common model of an SVN Project-based Repository is one with three sub-folders:  trunk, tags, and branches.
  • "trunk" is the main, and in most cases the only, part of the Repository that you use.  You typically Commit to the trunk, Check Out from the Trunk, and update from the Trunk.  Think of the Repository as a Tree -- it grows upward, and (unless you do something special) you deal with its "tip".
  • "tags" lets you place a "marker" on the Tree so you can go back to a "known place" in the Tree.  At this time, you don't need to worry about it.
  • "branches" lets you "go off in a different direction", another somewhat advanced topic that you should not use until you are pretty experienced with using Subversion.  [I created several branches the first 2-3 years I used SVN, and ended up deleting all of them.  I didn't create a useful Branch until about 6-7 years later].
  • Bottom line -- deal "almost all the time" with the trunk (which is the usual default, not needed to be specified except for Checkout.
• When starting, you create a Repository on the SVN Server, named for your Project (let's call it "BS SVN Demo").  If you follow the "usual model", you create trunk, tags, and branches folders in the Repository.
• On your PC, you have a Folder that you want to "link" to the SVN Repository.  The PC "version" of data saved in a Repository is called the "Working Copy".  So the first step is to take your Project (currently located in a folder called "BS SVN Demo", and destined to become the Working Copy) and save it into the just-created Repository.  You do this once, using the Import command.  You use the Import command from the TortoiseSVN right-click menu, specifying the trunk folder of the BS SVN Demo repository.
• So now you have a Repository.  Go to another PC (or to another Folder on your current PC) and do a CheckOut from Subversion.  Specify "BS SVN Demo/trunk" (and pay attention to the name that TSVN gives to the Working Copy -- you'll see it say "BS SVN Demo/trun" and when you type the final "k", the "/trunk" part of the Working Copy name will disappear.  When you type OK, you will get a fresh Working Copy of the most recent version (here, the only one) in the Repository.  You do Checkout only rarely, namely when you need a "fresh Working Copy".
• As you make changes to your Working Copy, you'll want to save the changes back to the Repository.  This process is called "Commit".  It only saves the changes, so tends to be much quicker than copying everything every time.
• If changes have been made in the Repository (say, on another computer with a separate Working Copy) and you want to update your Working Copy to the "latest version", you do an Update.
• The basic pattern is as follows:
  • Beginning of the day, Update (to be sure you "have the current version".
  • During the day, Commit at convenient points.
  • At the end of the day, Commit.

Hope this clarifies some points.  I recommend Fabiola's video (despite my quibble).

Bob Schor

[wiebe@CARYA]

---

@billko wrote:

The only issue I have with versioning software is not actually with the software; it's that if you even have one person who doesn't know what they are doing, it can cause headaches forever.

---

Biggest problems I had was with people not using it.

Commits once every two weeks (commit small changes).

Releasing executables without tagging (tag\branch when appropriate).

Not commenting at all (even a small message is better than nothing).

Headaches for sure, but I'm not sure if it would have been worse without SCC, although it's easy to get to depend on it.

[Yamaeda]

"I don't see that when I check files out.  I think you can manually tell TSVN to lock files and folders, and I think you can also change the checkout behavior in the settings, but I believe the default settings are not to mark files as "in use"."

Yes, that's a SVN setting. If you want more of a 'check out - check in' behaviour you can have it set Read only no checkins and a checkout will then flag it in the database and remove the read only-flag. It can be helpful to avoid checking in recompiled code that affects others.

A coworker that had been working too long solo in a repo was way too used to simply recomile and force commit any changes (since it used to be only him workin on the code) that he commited over other real changes several times ... In that case this would have been good.

/Y

[Bob_Schor]

---

wiebe@CARYA wrote:

---

Not commenting at all (even a small message is better than nothing).

Headaches for sure, but I'm not sure if it would have been worse without SCC, although it's easy to get to depend on it.

---

When I create a Repository, I set its Minimum Log Size to 40, which requires at least a 40-character Comment in order to Commit.  I occasionally have to re-commit because I had the Project File still open (almost a trivial Commit), so I add characters and say "Stupid Bob, he forgot once again to close the Project before committing." or something similar to hit the 40-character limit.

It is described in section B.2.2. of the TSVN Help.

Bob Schor

[billko]

---

@Bob_Schor wrote:

---

wiebe@CARYA wrote:

---

Not commenting at all (even a small message is better than nothing).

Headaches for sure, but I'm not sure if it would have been worse without SCC, although it's easy to get to depend on it.

---

When I create a Repository, I set its Minimum Log Size to 40, which requires at least a 40-character Comment in order to Commit.  I occasionally have to re-commit because I had the Project File still open (almost a trivial Commit), so I add characters and say "Stupid Bob, he forgot once again to close the Project before committing." or something similar to hit the 40-character limit.

It is described in section B.2.2. of the TSVN Help.

Bob Schor

---

I am embarrassed to say I've had to commit my project file separately too many times... and put in the same kind of comment.

[Bob_Schor]

---

@billko wrote:

---

I am embarrassed to say I've had to commit my project file separately too many times... and put in the same kind of comment.

---

By the authority vested in me by the Community and my Knighthood, You are Forgiven!  Shape up, man!

Bob Schor