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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/0b50d06d-c768-576c-41ed-3216184e98be%40gmx.de. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
