Am 19.12.2012 18:12, schrieb John Cowan:
> We are all so sick to the teeth of the "cow orker checks a file out to
> work on it but doesn't finish before going on vacation, have to email a
> ClearCase admin to break the when they get around to it" scenario that
> I don't want to even mention the existence of such a feature, as people
> will assume that it will be abused if only by accident.
Only that you cannot abuse it since everyone can choose to steal locks
when committing his files. No special permissions required. Of course,
both locking files unnecessarily and stealing locks unnecessarily can
result in "social consequences".
> Excellent point. When you do a ClearCase update you are asked the policy
> for that particular update: revert changes, ignore changed files, or
> rename changed files with a .keep extension. The second is the default
> instead of the more sensible third, and your choice is not sticky.
> I've added language to ask people to always update, even for a quick
> change (after all, such an update should be fast, no?)
It usually is. There are "features" that can be abused to make update
slow (like having hundreds of file externals in one directory), but
usually an update that does not pull any changes is very fast.
> Yes, I am somewhat abusing the term "conflict" to include automatically
> resolvable conflict. We work not with source code but with XML documents
> of many types, and I am less confident that Subversion can adequately
> resolve those by itself.
Will depend on the formatting of the XML file. Sensibly formatted XML
(with tags indented and on its own lines) work quite well with SVN,
having only one long line will make resolving conflict harder as even
with conflict markers you get one line with the old file and one with
the new file.
In that case it may be useful to point out that there are .mine, .rX,
and .rY files next to the conflicting file which you can feed to any
good domain-specific three way merge tool to resolve the merge there.
> I think the typical case will be some forgotten file that was cleared out
> but is found to be needed by some obscure process. Reverting to a year
> ago wouldn't make much sense.
"Revert to this revision" performs a different task than "Revert changes
from this revision" even though the icons are the same.
(There is also "update to this revision" which will just change the
working copy back to that revision to look at files - another update
will bring it back to current. It can be confusing to a newbie that
after accidentally choosing "Update to this revision", a "Revert to this
revision" is a no-op, as the current working copy is at that revision
already and therefore there is nothing to revert. But I don't think
details like this belong into a FAQ - as long as there is someone around
that can tell you to update back to current revision before trying to
revert anything.)
> By the way, is there an easy way to pick a specific change and generate
> a new change that exactly undoes it? People do commit things by mistake
> now and then.
That's what I was talking about. You will have to commit that new change
afterwards, though. (On command line, you can do it with a reverse merge
of that revision.) And, as any merge, it can result in conflicts you
have to resolve (or revert).
Regards,
Michael
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3037320
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-12-19 19:01:12 CET