Basic TortoiseSVN question

[swoo_quek]

Hi,

I would like to know the difference between the different "Revision" below?

For the "demo" directory, in my local drive (right-click -> Properties -> Subversion), the WC Revision is 3, and the Last Changed Revision is 1. And in the Repo-Browser, its revision is 1

So which is which?

[Stefan]

Hi,

The revision row in your 1st screenshot shows the last revision that path was modified. cmt (or one of the children in cmt) was modified in revision 3 while the last modification to the demo path was in revision 1.

The Revision: HEAD in the repository describes which revision of the entire repository you are looking at. HEAD means you are looking at the "last/current" revision of the repository. You can change it to show an earlier revision (f.e. revision 1) to see how the repository looks/looked in that older revision.

The working copy revision shown in screenshot 2 describes which revision your local working copy is at (revision 3 in your case). If someone else commits something to the repository, your working copy would still stay at revision 3 while the repository would then be at revision 4. If you update your working copy again, it will be updated to revision 4 then.

Regards,
Stefan

[swoo_quek]

Dear Luke1410,

Thanks for reply. I still have some doubts:

1. In the working copy, what is the use of even having a WC revision? I thought what matters most is the version that it last changed?

2. In my WC c:\cmt, let's say I have two files, file1.c, file2.c. If I SVN_update file1.c, I noticed that the revision of the folder c:\cmt remains unchanged. Isn't this flawed? Which means by just looking at the revision of the folder alone, I am NOT able to tell the revision of the files in the folder! I think this is chaotic, because the integrity "binding" the folder revision and file revision does not hold.. am I right?

[Stefan]

Hi,

On 23/04/2018 17:59, swoo_quek via TortoiseSVN wrote:
> Dear Luke1410,
> Thanks for reply. I still have some doubts:
>
> 1. In the working copy, what is the use of even having a WC revision?
> I thought what matters most is the version that it last changed?

It's not a WC revision. It's the revision of the repository your working
copy points at. You can always update your working copy to an earlier
revision of the repository. In such a case you get the earlier version
of all the files in the repository.
Imagine you use SVN to develop an application and release version 1.0
which corresponds to revision 200. You then keep on development and the
revision is now at 250. You the receive a bugreport for version 1.0 and
want to check out what the code looked like for that released version.
Hence you can update your working copy to revision 200 to review that
older code state.
In this case the repository is at revision 200 then. To continue
working, you'd then obviously update to the HEAD revision again.

There are dozens of use-cases where you'd end up with ur WC not pointing
to HEAD. I suggest you read up a bit on the web regarding version
control principles to get a rough idea of what this is for.

>
> 2. In my WC c:\cmt, let's say I have two files, file1.c, file2.c. If I
> SVN_update file1.c, I noticed that the revision of the folder c:\cmt
> remains unchanged. Isn't this flawed? Which means by just looking at
> the revision of the folder alone, I am NOT able to tell the revision
> of the files in the folder! I think this is chaotic, because the
> integrity "binding" the folder revision and file revision does not
> hold.. am I right?

> [...]
There is no such binding between a revision of folders and revisions of
files. SVN supports the concept of mixed revision working copies. See
[1]. Each file/folder has its distinct revision in the working copy.
Again, there are dozens of use-cases where this is comes in handy and
simplifies working with revisions. Imagine you want to create a modified
version of a large binary file you have in ur working copy, but of an
earlier version. The folder it is stored in has hundreds of large files.
Instead of having to update the entire folder to the earlier revision,
you can only update the one particular file to the old revision which
can be quite a time safer.
It's complex to visualize all the possibilities in a usable way with a
client like TSVN. At some point TSVN needs to make a decision between
complexity and usability/acessibility. I'm sure this is the reason why
there's no direct visualization of the sate that not all contained files
in a folder are at the same revision the containing folder is.
Note that it's up to the user to decide which workflow he follows. For
beginner's I'd always recommend to always update just the root-WC folder
and not get into mixed-revision working copies right away. Most users
won't require this feature IMO (at least not with common day-to-day
work) and for common use cases this concept is quite transparent to
users working with TSVN.

Regards,
Stefan

[1]
http://svnbook.red-bean.com/en/1.8/svn.basic.in-action.html#svn.basic.in-action.mixedrevs

[swoo_quek]

Hi Stefan,

Under what circumstances, would a commit increment the revision of a WC directory?

[Stefan Hett]

Hi,

On 5/2/2018 4:48 PM, swoo_quek via TortoiseSVN wrote:

Hi Stefan,

Under what circumstances, would a commit increment the revision of a WC directory?

A commit will only increment the revision of the file/folder you changed. So if your entire working copy is at revision 99 and you commit the file foo/bar.txt in revision 100 then bar will be at revision 100 while foo (and all the other files) will remain at revision 99.. To bring up everything to the same revision under foo you'd have to update foo.

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/49b8bd16-0d0f-4957-8c87-b9891266c665%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Regards,
Stefan Hett

[swoo_quek]

Dear Stefan,

I understand what you explained. But my question is actually:

Q1. Can I commit a folder (not files), and thus rev up its revision?

Q2. What do you mean by "folder I changed"?

   - does adding a new file (bar2.txt) to /foo, change the folder? Or

   - does changing bar.txt, change the folder /foo?

[Stefan Hett]

On 5/2/2018 5:52 PM, swoo_quek via TortoiseSVN wrote:

Dear Stefan,

I understand what you explained. But my question is actually:

Q1. Can I commit a folder (not files), and thus rev up its revision?

If you add a folder, delete it and/or rename/move it, then the whole folder which is impacted (and all its contained children) would end up to be at that revision of that commit.
If you add an SVN property on the directory and commit that prop change, the folder would end up at that revision with its children remaining at their current revisions.

Q2. What do you mean by "folder I changed"?

   - does adding a new file (bar2.txt) to /foo, change the folder? Or

   - does changing bar.txt, change the folder /foo?

By "[...] increment the revision of the file/folder you changed.[...]" I actually mean: "[...] increment the revision of the file or folder you changed.[...]". See the examples I gave above. F.e. you could rename the folder -> the revision of that folder would end up at the revision of the commit.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/85efb21a-02b7-4e7d-b777-07003851f361%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Regards,
Stefan Hett