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 ... 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
