Hi Stefan, Under what circumstances, would a commit increment the revision of a WC directory?
On Tuesday, April 24, 2018 at 4:46:48 PM UTC+8, Luke1410 wrote: > 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/49b8bd16-0d0f-4957-8c87-b9891266c665%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
