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? On Wednesday, May 2, 2018 at 11:40:05 PM UTC+8, Stefan_Ego wrote: > 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. > > > > > 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] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tortoisesvn/49b8bd16-0d0f-4957-8c87-b9891266c665%40googlegroups.com > > <https://groups.google.com/d/msgid/tortoisesvn/49b8bd16-0d0f-4957-8c87-b9891266c665%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > Regards, > Stefan Hett > > -- 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/85efb21a-02b7-4e7d-b777-07003851f361%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
