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 <cmpilato_at_collab.net
> <mailto:cmpilato_at_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
> <julianfoad_at_btopenworld.com <mailto:julianfoad_at_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 <cmpilato_at_collab.net <mailto:cmpilato_at_collab.net>>
> CollabNet <> www.collab.net <http://www.collab.net> <>
> Distributed Development On Demand
>
>
>
>
> --
> Stas Cherkassky
> email: scherkas_at_gmail.com <mailto:scherkas_at_gmail.com>
> phone: +972-54-4261959
>
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-01-14 22:58:09 CET