Quoting from Benjamin Pflugmann's mail on Fri, Nov 26, 2004 at 07:26:18PM +0100:
> > 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.
The option is meant to be similar to the --parents option in cp(1).
> 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.
I guess, the workaround in which I have to manipulate the files not in
package is not okay for me. I actually have more than 3000 files in my
repository, more than 40 packages, and not more than 200 files per
package. So, if your solution involves deleting almost all the files
many times over, don't expect any new year wishes from me :-) In any
case, just deleting the files doesn't seem to work (see below).
> > > 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?!
I thought that you meant that I should put shared files like
include/Makefile in pkg-common only and not in pkg1, etc. But, pkg1
requires include/Makefile to compile.
> * 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).
Not exactly. You also have to figure out which directories to remove.
For example, if no file under src/ is in pkg1, then there is no point
in tagging the empty directory src/.
> 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).
Unfortunately, a simple "rm" on files doesn't affect the tagging
process.
$ ls
a.c a.h
$ rm a.h
$ svn copy . $REPOS/tags/test-tag -m 'created tag test-tag'
Committed revision 2.
$ svn ls $REPOS/tags/test-tag
a.c
a.h
I even tried "svn up" to get a complex working copy:
<http://svnbook.red-bean.com/en/1.0/ch04s06.html#svn-ch-4-sect-6.2>
$ ls
a.c a.h
$ svn up -r0 a.h
D a.h
Updated to revision 0.
$ ls
a.c
$ svn copy . $REPOS/tags/test-tag2 -m 'created tag test-tag2'
Committed revision 3.
$ svn ls $REPOS/tags/test-tag2
a.c
a.h
So, "svn copy" seems to add files which are not in the working copy
magically!
> And if you script that, this solution is not any more error-prone
> than any other svn copy.
I meant that it could be error-prone if I also want to avoid tagging
empty directories.
--
Sunil Shetye.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 27 08:30:39 2004