On 7/20/05, Eric Fesler <ericml@audaxis.com> wrote:
> I'm indeed using subversion 1.1 on the server. However running svn up
> before the copy does not correct the issue (neither after).
>
I replied to your other email. Yes, this was a bug and I was using svn
1.1.3 when I tested this. I have not tried this on svn 1.2 (where it
might be fixed).
However, doing an "svn update" before I did the copy did solve the
problem for me. It appears that Subversion doesn't register that a
working directory is at a newer version once a commit is done (as seen
via the "svn info" command). That's why when you simply refer to the
directory as ".", it copied the earlier version of the directory.
I'll try this on Subversion 1.2 to see if I still run into this issue.
On 7/20/05, Eric Fesler <ericml@audaxis.com> wrote:
> Thanks Ben for the quick reply.
>
> Ben Collins-Sussman said the following on 07/20/2005 08:27 PM:
>
> >
> > On Jul 20, 2005, at 12:12 PM, Eric Fesler wrote:
> >
> >> Hi,
> >>
> >> I'm having some trouble with the delete of a directory.
> >>
> >> I had in my project a directory named "test".
> >> It has been committed to the repository and after a while deleted from
> >> the working copy. The deletion has been committed and the directory
> >> does
> >> not appear anymore in the HEAD and svn status says that everything
> >> is in
> >> line with the repository.
> >>
> >> Up to now, everything seems normal !
> >>
> >> The issue raises when I'm trying to generate a new tag.
> >
> >
> > The far more common (and much faster) way to make a tag is
> >
> > svn copy URL1 URL2
>
> This indeed is working properly
>
> >
> >
> >>
> >> I'm using:
> >> svn copy . [repository path]/tags/release-X.X
> >>
> >> Then, I make a checkout of release-X-X
> >> using: svn checkout [repository path]/tags/release-X.X [targetDir]
> >>
> >> and in the [targetDir], I "test" directory has been recreated with its
> >> old content!!
> >
> >
> >
> > I think this may be a bug that was fixed in svn 1.2.
> >
> > Either way, running 'svn up' before doing the copy will avoid the
> > problem.
> >
> I'm indeed using subversion 1.1 on the server. However running svn up
> before the copy does not correct the issue (neither after).
>
> Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 20 23:02:49 2005