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>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
> >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>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
--
Stas Cherkassky
email: scherkas_at_gmail.com
phone: +972-54-4261959
Received on 2010-01-14 22:36:52 CET