Svn checkout oddity

[zaval]

I've stumbled on a weird incostistency in Svn behavior.

I have a USB stick with 5 repositories in it. They all are organized
the same way as recommended in the Svn book: every repository
has its own "project root" directory, in which version control,
organizational dirs - "trunk", "branches" and "tags" are placed.
Behind them a source tree themselves goes.
So, with one of the repos and only it, this oddity appears.
Normally, when I do checkout a repo for getting a new working copy,
for example on another computer, I type:

Code: Select all

>svn co file:///R:/Svn/Project1Root/trunk pr1

and it outputs, something like this:

Code: Select all

A    pr1\src
...
A    pr1\src\source.c
Checked out revision 33554432.

But for one repo, the very same command:

Code: Select all

>svn co file:///R:/Svn/osloader/trunk osl

results in a sightly different output:

Code: Select all

A    osl\arm64
...
A    osl\fs.c
 U   osl

The last line is the difference: it reports, that the directory
"osl", we chose to place our working copy into, has been updated,
that's why 'U' in the 2nd column. But why the same line doesn't appear
for the other repos? This behavior replicates no matter the differencies
in doing the checkout in regard of how the directory is being created - by you
via, say, mkdir or by Svn implicitly
or either you operate from its parent directory
or from it, that is even if you, being in the dir, will type:

Code: Select all

>mkdir osl
>cd osl
>svn co file:///R:/Svn/osloader/trunk .

It still will report it like this:

Code: Select all

A    arm64
...
A    fs.c
 U   .

Why this difference? Has anybody in this git ruled world stumbled upon
this or does know, why it happens or it's a Heisenbug? The Svn version
is 1.9.5 (r1770682).

[BigBuda]

ok, I only use Subversion and I can't say I've ever come across that happening. My first thought before reading the rest of your post was "probably he already had the directory there", but even so, if the checkout detected the directory and executed an update instead, it would still show the revision number.

Also, it seems that the osloader repo isn't showing paths during checkout, only filenames. Is the repo completely flat, or are the files inside the trunk folder of the osloader repo distributed in subdirectories?

[zaval]

ok, I only use Subversion and I can't say I've ever come across that happening. My first thought before reading the rest of your post was "probably he already had the directory there", but even so, if the checkout detected the directory and executed an update instead, it would still show the revision number.

Thank you for the response. In this case, Svn also prints the line "checked out revision NNN" as the last one, I just forgot to mention it.

Also, it seems that the osloader repo isn't showing paths during checkout, only filenames. Is the repo completely flat, or are the files inside the trunk folder of the osloader repo distributed in subdirectories?

this repo is like others: an ordinary file system subtree with both files and directories behind the trunk dir. That case, where it looks, like isn't showing paths in its output is when you do checkout from the checkout directory, "osl" in this example, if you did checkout from its parent dir, it would show them. I should have put a better output example. In fact, in the above example "arm64" is an added directory and "fs.c" is an added file, both in the "trunk" directory. Should I have added something in "arm64" also, it would reflect that. In other words, it did show the paths, just in the case of the checkout from "osl" it omitted "osl\" itself (or '.\' part) in the output.

So, it's a mystery? I hope, it won't cause wiping my work into oblivion.

[BigBuda]

It shouldn't be a reason for concern. Have you tried browsing the repository with tools like Tortoise SVN just to make sure? I avoid developing on Windows at all costs, but when my students have to use it, I recommend they use Tortoise SVN. Check it out and see if you detect any differences in behavior.