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

Re: Newbie Qs about organizing repository and getting checkouts to go where I want them

From: Ulrich Eckhardt <ulrich.eckhardt_at_dominolaser.com>
Date: Fri, 16 Mar 2012 09:29:27 +0100

Am 14.03.2012 16:11, schrieb Chris Chiesa:
> This is kind of long. Please forgive me; I am trying to get up and
> going and don't have a lot of time.
>
> Trying to figure out usage patterns for SVN for my Windows app and
> DLL projects.
>
>
> Backstory:
> --------- Historically, I have a directory containing all the source
> files for a single version of a single project, PLUS the specific
> versions of the specific .lib and .dll files that project needs at
> build / run (test) time, PLUS the test data.
>
> Having tried a few times to read the SVN book, and not been able to
> get far, here is my understanding of how to use SVN:
>
> - put the project source files into a particular subdirectory of a
> repository (1, below). At first into 'trunk,' but with the option to
> 'branch' different variants of the project (2, 3) at any time.
>
> - "Updating" a file replaces its earlier version, in the sense that
> if I check out the "HEAD" revision of the entire directory I get the
> latest version of every file.

Stop right here: You are mixing up the terms "update" and "check out".
Check out creates a new working copy with the content at the HEAD
revision (unless you specify a different revision). The HEAD revision is
just a symbolic name for "latest revision in the repository" and assumed
as default revision is several SVN operations.

On the other hand if you update a file (or multiple files/directories),
differences(!) are fetched from the repository into the working copy. If
the working copy wasn't modified since last update, it will then have
the same content as the files in the repository, otherwise the changes
from the repository and those from the working copy will be mixed. If
the repository files didn't change since last update, there are
obviously no differences and the working copy isn't modified.

In order to detect changes, the working copy has a BASE revision[1],
which is again a symbolic name. This revision is the revision the
working copy is based on. It is initially specified on checkout (current
HEAD by default) but updating a working copy will change this revision
(again, to the now current HEAD by default).

> I can also check out earlier versions of of each file by specifying
> the version I want

Yes, Subversion is a time machine. ;) You can update a single file to a
certain revision and then you get the earlier version. You can also
check out a new working copy of that earlier revision.

> -- or can "tag" a collection of versions at a given time (e.g. when
> I build a "release" of my app or DLL) and check out that whole
> collection all at once at a future time.

Tagging is just copying within the repository. Other than the revision
numbers, you can then assign a name to the tag that is human-understandable.

> (1) The first time I've done this, I had to use "Add File" for each
> individual file. That was tedious. Is there a way to add a whole
> set of files at once? "Add Folder" creates a subfolder in the
> repository, which I don't think is what I want (see structure below).

You can mark multiple files in the Explorer and add them. You can also
add them from the commit dialog when you choose to display unversioned
files. I don't think there is a really easy way to achieve this, but you
don't do that often. Once you imported a project, you typically treat it
as a whole, only adding or deleting files now and then.

> Am I organizing the repository inappropriately? I assume source
> files should be directly in 'trunk,' not a subfolder thereof.

Firstly: All this is up to you to decide, Subversion itself doesn't
care. However, there are two customary ways to organize things:
1. You have trunk/branches/tags at the top level with a folder for each
project underneath.
2. You have a folder for each project at the top level with a
trunk/branches/tags folder underneath.

> It's not clear how I would update/branch a subfolder of 'trunk.'
>
> (2) Do I have to branch each individual file, or do/can I branch the
> whole 'trunk' at once?

You branch on a per-project base. If you have a library with according
unit tests, examples and documentation, that would be a project.

> (3) Can I "go back" and branch from a version of a file "earlier than
> the HEAD?" Can I branch from a previously "tagged" set of (versions
> of) files?

Yes and yes.

Concerning your repository structure, you basically chose variant 2,
only that you added a "Products" folder at the very top level (I don't
know why) and that instead of a single "project" folder you chose a
two-level "category/project" hierarchy. This is okay, you only have to
know that if someone talks about the "project" folder it translates to
your "category/project" combo.

> I am having a little trouble getting Tortoise SVN to do what I want,
> but maybe what I want goes against the principles of SVN.
>
> Basically, I want to check out the source files from
> Apps/AppOne/GUI/trunk, and the .dll and .lib from
> Apps/AppOne/Libraries, into the SAME working directory.

Yes, this is a problem. One is that you want this to be the same working
copy. The other is that you are versioning non-source files. I guess you
should be able to locate reasons not to version non-source files
(repository bloat, non-mergable etc). Now, what you can't do is to check
out into the same directory. You can nest working copies (i.e. store one
working copy inside another), which is why SVN only gave you a warning.
However, a working copy always begins with a directory, you can't check
out single files, so you will never get the dlls into the working copy
for your trunk. What you can do to some extent is to "svn switch"
certain an (empty placeholder) file to a URL in a different URL, but
this gets messy.

What I would rather do is to define a placeholder in your project setup
by which to locate the libraries. That way, you can also tell it to
search in a working copy of the library somewhere on your computer. To
some extent you can already achieve this with the PATH environment
variable. In other words: Avoid hardcoded paths!

Good luck!

Uli

[1] Actually, every versioned element of the working copy has its own
BASE revision as you can update them independently.
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2936613

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-03-16 09:29:44 CET

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.