On Fri 2004-11-26 at 16:12:32 +0530, Sunil Shetye wrote:
> Quoting from Benjamin Pflugmann's mail on Thu, Nov 25, 2004 at 10:33:27PM +0100:
> > You can prepare a working copy to represent what you want to be tagged
> > and then tag the working copy.
[...]
> > should do what you expect (so long as I understood correctly what you
> > expect).
>
> Yes, you have understood my problem correctly. If you do look at
> Method 3 in my original mail,
>
> <http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=21572>
>
> it is similar to the method you have described. The only difference is
> that it does a "svn copy" first and then "svn rm" on the tag
> directory.
There is another difference: The method I suggested needs only one
commit and so only creates only one revision (ignore that, if you
don't (have to) care about the number of revisions / commit mails).
> And my original question was:
>
> Is it possible to have an option like "--parents" to "svn copy" to
> make tagging of some files easier?
Sure it would be possible. Whether the main developers would support
such a feature is another question. Maybe you did this in an earlier
email, but a good start would to post a more specific explanation of
how such a feature would work, as from the descriptions I read up to
now, I am not clear what exactly --parents is meant to do.
> Why should I do tagging in a roundabout way when this one option is
> going to solve all my problems. With your solution, per package, I
> will have to:
>
> 1) checkout the repository,
> 2) figure out what files and directories to remove,
> 3) remove them,
> 4) tag the remaining.
>
> This obviously is a sub-optimal (and idiotic, IMO) way of tagging
> files. Not to mention, network-intensive. And error-prone, if I don't
> figure it out right!
IMHO, you overshoot the mark here. You presented problem and I
provided a workable solution. If you are not ready to accept a
work-around, but want to change subversion's behaviour, fine, just say
so (and please don't present bogus/assumed arguments*).
In that case I suggest you follow up the --parents idea on the dev
list. I will be out of this (because I am not interested in that
feature), but don't let that stop you.
If, on the other hands, a work-around is okay, but the one I presented
just doesn't do the job fully yet, tell me more about it, and I will
try to solve the remaining issues with you.
> > Of course, splitting up the packages in pkg1, pkg2 and pkg-common
> > might be the better long-term solution.
>
> Each individual package is meant to be compiled independently.
I don't see a contradiction with what I said?!
Bye,
Benjamin.
* I don't see the problems with the number of steps (you don't need to
check out a new working copy, you already have one, don't you?).
Nor with figuring out the stuff to remove (you obviously have a list
of what to tag; it's easy to get a list of all items; so the list of
items to remove is a simple operations on sets).
And if you use "svn revert" at the end to restore the working copy
to the full state, the network traffic involved surely isn't
significantly more than in your preferred solution (if --parents
were supported).
And if you script that, this solution is not any more error-prone
than any other svn copy.
As I said above, if you don't see how the work-around accomplishes
what I claim, I will be happy to work with you on that. Yes, it's
not as nice as if it was a built-in feature. But that's why it's
called work-around.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 26 19:37:55 2004