"Sander Striker" <striker@apache.org> writes:
> > 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?
>
> Can't we mark the directory as 'dirty' after the commit (of the deletion)?
> We do bump the dir rev to 15 in this case, but also set the dirty marker
> on it. This way we know the rev of the dir should be at rev 15, but it
> needs updating to be in the state rev 15 is in.
Yes indeed, this is another solution!
In other words, if a directory is marked "dirty", then when we send
our update state-report to the server, we enumerate *all* immediate
children in the report, just like CVS does all the time.
I like this solution -- it's much simpler to implement and maintain.
Feels cleaner to me.
>
> > We are only allowed to bump working-copy directory revisions in
> > updates, or when we commit a propchange to a directory.
>
> Hmmm, committing a propchange doesn't update the directory contents
> either, so how is that not a problem? Or does your wc need to be
> fully up to date at commit of the propchange? Does it fail otherwise?
Indeed, it's true. You currently can't commit a propchange on a dir
unless it's fully up-to-date. The server will reject the commit
otherwise. A lot of people hate this behavior. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 18 17:26:52 2002