[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: problem arising from early entry deletion

From: Ben Collins <bcollins_at_debian.org>
Date: 2002-03-18 03:29:36 CET

On Sun, Mar 17, 2002 at 08:23:16PM -0600, Ben Collins-Sussman wrote:
> Ben Collins <bcollins@debian.org> writes:
>
> > >
> > > Principle: "Lying to the server is bad." :-) We need to stop doing it;
> > > what's the best way?
> > >
> >
> > Could we instead (in your example) mark "." as rev=10 instead of leaving
> > it as 9?
>
> No, because that would be a Lie too.
>
> We don't *know* that we have revision 10 of the directory; we merely
> created it by committing the deletion. In the general case, suppose
> our commit created revision 15. It would be a lie to say we have
> revision 15 of the directory after the commit; what if someone added
> a file to the directory in revison 12?
>
> We are only allowed to bump working-copy directory revisions in
> updates, or when we commit a propchange to a directory.

Thought about that several minutes after I sent the email. Seems you
can't really avoid having the old way in place. I know it has caused me
a lot of problems with my project. Me being the only one committing to a
repo, I still had to "svn up" after each commit to prevent conflicts
from popping up (presumably because of this issue).

-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/       Ben Collins    --    Debian GNU/Linux    --    WatchGuard.com      \
`          bcollins@debian.org   --   Ben.Collins@watchguard.com           '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 18 03:34:30 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.