> > > 'svn revert' just copies the text-base on top of the working file.
> > > But the whole point here is that the text-bases are *wrong*. They're
> > > wrong in the sense that the text-bases no longer are identical to
> > > what's in the repository, which is our cardinal rule.
> >
> > Hmmm... perhaps there should be a command or option that forces an
update of
> > the text-base from the repository. After all, your example alters the
> > text-base by hand intentionally, but someone could do that accidentally;
for
> > example, using a wildcard that affects more files than intended.
> That's why our text-base files end with .svn-base (so they're not
> easily found by wildcards or 'find'), and why they have read-only
> permissions.
Just because it's difficult doesn't mean it won't happen. Some development
environments helpfully ask you if you want to override read-only protection
when you save a file.
But if I'm working on a 5,000-file project and the text-base of, say, 100
files is corrupted, shouldn't I have the option of forcing a refresh of the
text-base from the server, rather than a)fresh check-out or b) attempting to
figure out what, exactly, is wrong?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 14 23:28:58 2003