On Thu, Jan 14, 2010 at 1:36 PM, Stas Cherkassky <scherkas_at_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 <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-20 04:32:15 CET