Re: Request for a review of an internal FAQ

Michael Schierl scripsit:

> In my experience with people who come from source control tools that
> follow the lock-modify-unlock scheme, it is helpful to tell there
> is in fact a "Lock" command available in (Tortoise-)SVN, which will
> "suggest" to other committers not to commit to this file right now
> (can be overridden, i. e. the lock can be "stolen", though).

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.

> If making the changes took you some time, preferrably do an update
> before the build. Unlike other source control systems (don't know
> about ClearCase),

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?)

> The most likely case for a commit to fail in my experience is not
> a conflict, but just a file that was edited by someone else in a
> non-conflicting way.

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.

> The "Edit conflict" dialog of TortoiseSVN is helpful for resolving
> conflicts in a "visual" way.

Since we have lots and lots of different editors in use from full IDEs to
Oxygen to "ex" (yes, I edit in "ex" quite a lot), I'd rather ask people
to use their editor so as to lower the learning curve for now.

Expert convenience is not always the same as newbie convenience, which is
about learning as little as possible. (Unless you're a hacker like me,
who usually wants to learn as much as possible.) But if we were all
like that, I wouldn't be writing this FAQ.

> Especially after merging a conflict it is a wise idea to have a look
> at the diff again to make sure you did not accidentally throw out
> changes in your merge.

Good point. Added.

> (Edit conflicts can also be invoked from the context menu of the update
> dialog after you received a conflict in an update; you don't have to
> wait until you want to commit or open a commit dialog if you prefer
> to fix the conflict right away. But I guess again a matter of taste.)

Just trying to KISS.

> Depending on what files you manage, having a good IDE integration can
> help you rename files inside the IDE.

As I say, not all our users use an IDE at all, never mind the same IDE.

> In case you accidentally renamed a file the wrong way, you can either
> rename it back and rename it again the right way,

Thanks, I'm adopting this language.

> As often deleting a file will also result in changing some other code,

In base ClearCase you need an administrator to undelete a file once the
change is committed, so we are all in the habit of never deleting anything.
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.

> You can also double click a (not conflicted) file in the commit dialog
> to view a diff. In case you have lot of files with only one or two lines
> changed and want to check nothing else crept in, you can also obtain
> a diff file for more than one file at once from the commit dialog.

I don't think most of our users have much experience looking at diffs;
they use various diff tools of their own choice. I added a note that
the diff tool can be changed.

> In some scenarios when lots of files need to be reverted, it may be
> easier to just delete the files and then update the working copy to
> get the old version back.

Adopted this language.

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.

> HTH,

Thanks a million. (We Americans don't think a thousand thanks are
enough, for some reason.)

-- 
De plichten van een docent zijn divers,         John Cowan
die van het gehoor ook.                         cowan_at_ccil.org
      --Edsger Dijkstra                         http://www.ccil.org/~cowan
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3037292
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].