On Thu, Jan 14, 2010 at 1:36 PM, Stas Cherkassky <scher...@gmail.com> wrote: > Michael, > > I think you are right - Subversion just wasn't designed for this > methodology. > But I can't believe SVN users don't have the same problem. I wonder how they > solve it ...
We have the same problem, but our 'solution' is to just live with it. This comes up periodically, and is a capability that users miss (compared to CVS.) > In other words, the sparse tag is just a mean to achieve what I need, which > is a communication > between sub-module designers and integrator. How is this supposed to be done > in SVN ? > How does integrator knows which version of each sub-module to take as a > release-candidate > for next integration ? > > The "view attached to tag" that you suggested is interesting (it resembles a > bit a tag implementation > in Perforce, where tag is an object which knows all files/versions it's put > on - which, IMHO is the best), > ... but only resembles. In my case there is no special goal to reproduce > that partial tree. I need to collect a few sub-modules to build a module > (this is hierarchical, the module may in turn be only part of the project). > And, as far as I understand, such "view" attached to a tag would not help me > to achieve this goal. > > thanks, > Stas > > On Thu, Jan 14, 2010 at 6:39 PM, C. Michael Pilato <cmpil...@collab.net>wrote: > >> Stas, you are quite right that the messaging here is important, if only to >> avoid hurt feelings. Your use-case is a valid one, and we'd all do well >> not >> to discount it. But Subversion simply wasn't designed to accommodate it. >> And this isn't even a small "oops we overlooked it" thing. This is a >> fundamental difference between the tagging and branching paradigms in CVS >> and Subversion -- a difference introduced intentionally when Subversion was >> conceived. >> >> I wonder: if you could attach to your tag a view specification that, upon >> checkout of the tag, would "kick in" and cause a working copy to be >> constructed sparsely as defined in that specification, would your concerns >> be alleviated? My line of thinking is this: some work was done to build >> out the working copy that serves as the source of your copy. That's work >> that might need to be done again someday. It would be nice to preserve >> that >> work a non-destructive fashion: to remember the sparse configuration of >> your tree so that it can be "replayed" later, or perhaps by someone else. >> Well, what if you could marshal that sparse configuration into the >> repository in some fashion so that it could be applied to tags created from >> your working copy? What complications or problems does this introduce in >> your situation? What problems does it alleviate? >> >> >> Stas Cherkassky wrote: >> > Julian, >> > >> > thanks you for your reply. >> > Your approach may technically work, but, I am afraid, it's not realistic >> in >> > real large project. >> > >> > The [everything except dirA and dirB] part may be quite complicated for >> > large sparse tree. >> > >> > The second approach (multiple svn cp WC URL) is also cumbersome and >> requires >> > multiple commits. >> > It also won't work if some files were already tagged before (you can't >> svn >> > cp over existing file). >> > >> > Both approaches are not easy to automate (too many cases to consider). >> > Just consider, what will happen 2nd time, when user B wants to update the >> > tag in his WC. Some files were tagged before, some - not. They may be in >> > the same dir, deep inside the tree. >> > >> > Just compare it to 'cvs tag -R -F tagX myproj'. The -F switch would tag >> > untagged files, and move tag on tagged files. Whatever files I have in my >> > WC. In one simple command. >> > >> > You may point our (correctly) that this feature was not requested or was >> not >> > considered important enough - after all it's open source community, and >> > developers do what they think is important and interesting to them. And >> > this is all correct. Incorrect is to claim that SVN does have the >> ability. >> > Even if it technically does, its absolutely unusable (all IMHO, of >> course). >> > The only real solution that I can see, it to have some switch for 'svn >> cp' >> > that will do exactly what's needed - including override files already >> under >> > the ^/tags/ dir.. >> > >> > thanks, >> > Stas >> > >> > >> > >> > On Wed, Jan 13, 2010 at 8:00 PM, Julian Foad <julianf...@btopenworld.com >> >wrote: >> > >> >> Hi Stas. >> >> >> >> Your question raises an important issue: "What are the semantics of >> >> sparse directories?" You expected "svn copy" to copy just the parts that >> >> are present in the WC, whereas in fact it copies the whole logical tree. >> >> There is a reason for that, but I think it is not clear how a user >> >> should expect each Subversion command to behave. >> >> >> >> In this email I will just address how it works at the moment and how to >> >> achieve the tagging that you wanted. I will start a separate email >> >> thread to discuss the semantics of sparse directories. >> >> >> >> >> >> Stas Cherkassky wrote: >> >>> I don't want to remove parts of the tree from the repository. >> >>> What I want is, effectively, a way to independently mark separate >> >>> parts of the tree with the same tag. >> >>> (I tried to explain it in my example). I don't see how your method >> >>> (using svn rm) does it. >> >> I'll explain my method using "svn rm" first, and then the method using >> >> "svn copy" with multiple source arguments. >> >> >> >> You don't exactly want to remove parts from the repository, but one way >> >> of thinking about what you want to create in the repository (the tagged >> >> data) is a copy of your normal working tree except with some parts >> >> removed. A common and flexible way to create a tree in a Subversion >> >> repository is to create it in a WC and then commit (or in this case >> >> copy) it. That's what my suggestion was for. >> >> >> >> More precisely, >> >> >> >> svn rm myproj/[everything except dirA and dirB] >> >> svn copy myproj ^/tags/rel_X/ >> >> >> >> And then if you want to restore your WC to how it was, you can revert >> >> the parts that are scheduled for deletion: >> >> >> >> svn revert -R myproj/[everything except dirA and dirB] >> >> >> >> >> >> Another way of thinking about the task is to ask Subversion to copy only >> >> the parts you want: >> >> >> >> $ svn copy --parents myproj/dirA myproj/dirB ^/tags/rel_X/myproj/ >> >> Committed revision 2. >> >> >> >> $ svn log -vq -c2 >> >> ------------------------------------------------------------------ >> >> r2 | julianfoad | 2010-01-08 10:37:34 +0000 (Fri, 08 Jan 2010) >> >> Changed paths: >> >> A /tags/rel_X/myproj >> >> A /tags/rel_X/myproj/dirA (from /myproj/dirA:1) >> >> A /tags/rel_X/myproj/dirB (from /myproj/dirB:1) >> >> ------------------------------------------------------------------ >> >> >> >> There is a limitation with this form of the copy command. With a single >> >> "svn copy" command, all the specified source objects (dirA and dirB in >> >> this case) are created as direct children of the target directory. There >> >> is no way to extend that example to make myproj/dirC/foo go to >> >> ^/tags/rel_X/myproj/dirC/foo at the same time as copying dirA and dirB. >> >> However, you can extend a tag by making a further commit to it with a >> >> second copy command, unless committing to a tag is disabled in your >> >> repository. So you could do: >> >> >> >> $ svn mkdir ^/tags/rel_X/myproj -m "New tag. Incomplete." >> >> $ svn copy dirA ^/tags/rel_X/myproj/ -m "Incomplete." >> >> $ svn copy dirB ^/tags/rel_X/myproj/ -m "Incomplete." >> >> $ svn copy --parents dirC/foo ^/tags/rel_X/myproj/dirC/foo >> >> -m "Completed tag for rel_X of myproj." >> >> >> >> >> >>> If a tag is a property of a file (like in CVS), it's natural operation >> : >> >>> cvs tag -R dirA -t relX # tags whatever files and versions I have in >> >> WC >> >>> and then >> >>> cvs tag -R dirB -t relX >> >>> In the end I have both dirA and dirB tagged with same tag relX. >> >> You can certainly do the equivalent thing in Subversion: it is the "svn >> >> copy" method that I described above. >> >> >> >>> If a tag is an object (like in Perforce), and it's property is a list >> >>> of files/versions it applies to, it's also easily achievable in very >> >>> similar manner - 2nd p4 tag call would just add more files to that >> >>> property of the tag object. >> >> That is also like the "svn copy" method that I described above. >> >> >> >>> With SVN's implementation of tags (logical directory in repo), it >> >>> would also be possible, had 'svn copy' behave like I suggested. >> >> That is true. >> >> >> >>> IMHO, this way is more intuitive - that's what unix copy command would >> >> do. >> >> >> >> The Unix copy command is not a fair comparison, because a normal Unix >> >> directory is not a temporary working representation of the real data >> >> stored on the server, and so does not have a way to mark certain files >> >> and directories as "excluded from the local working copy". Or, looking >> >> at it another way, if you mark some of the directory's children as >> >> hidden (by renaming them to start with a dot in Unix), then a copy of >> >> the whole directory will still include those hidden items. >> >> >> >> >> >> - Julian >> >> >> >> >> >> >> > >> > >> >> >> -- >> C. Michael Pilato <cmpil...@collab.net> >> CollabNet <> www.collab.net <> Distributed Development On Demand >> >> > > > -- > Stas Cherkassky > email: scher...@gmail.com > phone: +972-54-4261959 >
