I suspect that most folks that have this problem had it long before sparse checkouts was introduced as a feature. I mean, there's nothing about sparse checkouts that's specific to the goal you have in mind, right? So I suspect those that have come before you have taken an additive approach to the problem (versus the somewhat subtractive nature of sparse checkouts). Maybe they've used skeletal trees with svn:externals that pull in particular sub-modules. Or maybe they've hand-constructed their modules with appropriate copies and deletes and such. Or maybe they do this kind of configuration in the integration/build scripts. As I'm sure you can imagine, people can get awfully creative with their development processes. :-)
Something that I don't *think* I've mention before as an option to you is to consider extending your sparse checkouts by a single level, scheduling the deletion (pruning) of those extensions, and then copying that. Allow me to explain. Say today you do this: svn checkout --depth empty REPO-URL module-to-be cd module-to-be svn update --set-depth infinity submodule1 svn update --set-depth infinity submodule3 svn update --set-depth infinity submodule8 cd .. svn cp module-to-be NEW-REPO-URL # Oops! Got the whole tree instead of just the three modules I wanted Consider this route: svn checkout --depth immediates REPO-URL module-to-be cd module-to-be svn update --set-depth infinity submodule1 svn update --set-depth infinity submodule3 svn update --set-depth infinity submodule8 svn delete [everything else in this directory) cd .. svn cp module-to-be NEW-REPO-URL # Now I get a copy of everything minus the stuff I don't want! svn revert -R . # so you don't accidentally commit those deletions I've presented a simplified use-case, of course, but perhaps it can scale to the degree that you need it. Just trying to add more goodies to the bag of tricks you might consider here. Stas Cherkassky 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 ... > 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 > <mailto: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 <mailto: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 <mailto:cmpil...@collab.net>> > CollabNet <> www.collab.net <http://www.collab.net> <> > Distributed Development On Demand > > > > > -- > Stas Cherkassky > email: scher...@gmail.com <mailto:scher...@gmail.com> > phone: +972-54-4261959 > -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
