RE: Atomicity of locks and needs-lock

> Ahh, but the question then becomes - how is it helpful when a 
> file shows as unlocked in my local cache and does not say 
> that it needs a lock?

I might be misunderstanding your question, but I think you're talking
about locks that are not locally known, because there hasn't been a
recent enough update, right?

At first pass, in order to have any benefit you have to perform an
update.  But it's still an improvement, because right now the
information isn't shown, *even if* you perform an update.

In the future, I would like to see a few improvements to this, but take
one step at a time and not right now.  For example, since the local
cache of remote lock info describes the repository files and not
necessarily the local files, it is actually safe to update the local
cache on *either* an update or a status check.  

So it then becomes safe to perform a periodic status check silently,
which would ensure that you always have lock info as recent as n
minutes.  With no risk to anything else you might be doing.

Automatically reply to group instead of to individual

Out of curiosity,

Is there any way to automatically reply to the group instead of to
individual here, or is that a global setting applied to all users in
this group?

If it's a global setting, I assume it's not worth while to change it.

Re: Atomicity of locks and needs-lock

Edward Harvey wrote:
>> Ahh, but the question then becomes - how is it helpful when a 
>> file shows as unlocked in my local cache and does not say 
>> that it needs a lock?
> 
> I might be misunderstanding your question, but I think you're talking
> about locks that are not locally known, because there hasn't been a
> recent enough update, right?
> 
> At first pass, in order to have any benefit you have to perform an
> update.  But it's still an improvement, because right now the
> information isn't shown, *even if* you perform an update.

But then the problem is that a user could always assume that a file
without needs-lock is one that could be edited/updated without locking
and thus would not have a lock.

In this new way, one would have to try to do an update before starting
to edit a file - but that would not be enough, since while editing someone
could then lock the file (and add the needs-lock attribute) so the only
safe way to edit a file would be to always lock a file.  Thus, in a repository
with such rules, all files would need to be treated as needing to be locked
before editing.  There is no other way to fix the race condition since
non-locked editing will never be an atomic operation.  (It is the lock that
makes it somewhat atomic... at least to all other potential editors)

> In the future, I would like to see a few improvements to this, but take
> one step at a time and not right now.  For example, since the local
> cache of remote lock info describes the repository files and not
> necessarily the local files, it is actually safe to update the local

Re: Atomicity of locks and needs-lock

[Michael Sinz]
> In this new way, one would have to try to do an update before
> starting to edit a file - but that would not be enough, since while
> editing someone could then lock the file (and add the needs-lock
> attribute)

A parallel situation occurs with ordinary WC merges - in fact it's
exactly the same situation.  If a user wants to minimize the
possibility of merge conflicts that she will have to sort through by
hand, she does 'svn update' before starting a major new feature that
would be likely to generate such conflicts.  This doesn't guarantee
anything - her coworker could still commit stuff to the repository
after she updates - but it reduces the chances of merge problems.  The
only way to reduce such a chance to zero is to lock the files yourself,
but I daresay that is usually overkill.

Locks are a similar story - in addition to enforcing that the
repository does not change out from under the user who locks a file,
they are (or should be) an advisory mechanism (yes, I said "advisory")
telling other users that they should be careful editing locked files,
because of an increased chance of merge conflicts later, after the
files are unlocked.

You can't eliminate these kinds of race conditions with subversion's
architecture, all you can do is train users to minimize the chance of
problems by such habits as using 'svn update' frequently, as well as
good old-fashioned team communication.  But really, why _shouldn't_ the
fact that a file is locked by a given user be communicated to other
users, when the opportunity presents itself ('svn update')?  Surely you

[PATCH] Update links.html for CodeWarrior plugin

[[[
Update links.html now that the CodeWarrior plugin is open source.   
The link also changed.

* www/links.html: Modify CodeWarrior plugin link to remove "not  
currently open source" text.  Change link.
]]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe <at> subversion.tigris.org
For additional commands, e-mail: dev-help <at> subversion.tigris.org

[l10n] Merging changes from trunk to branch

Hi all,

I have not been active on translating subverion.po for a long time,
and currently I decided to clean the Traditional Chinese version up.

I have done fuzzy messages and new messages on trunk, and commit them
back.  But after I ran 'make locale-gnu-po-update' and po-merge.py, I
found there are still fuzzy messages.  After reading TRANSLATING file,
it says I can translate messages which never existed on trunk, and
tweak message options.  But I'm not sure if I can touch fuzzy
messages.

And about the untranslated messages.  I found some of them do exist on
trunk, but with a different path, like:

  # 1.3.x Branch
  #: clients/cmdline/copy-cmd.c:106 clients/cmdline/delete-cmd.c:64
  #: clients/cmdline/mkdir-cmd.c:66
  msgid "Local, non-commit operations do not take a log message"
  msgstr ""

  # trunk branch
  #: svn/copy-cmd.c:108 svn/delete-cmd.c:64 svn/mkdir-cmd.c:66
  msgid "Local, non-commit operations do not take a log message"
  msgstr "**TRANSLATED MESSAGE**"

Some fuzzy messages are just like this, too.

Can anyone tell me what should I do to deal with them?

Re: Atomicity of locks and needs-lock

Peter Samuelson wrote:
> [Michael Sinz]
>> In this new way, one would have to try to do an update before
>> starting to edit a file - but that would not be enough, since while
>> editing someone could then lock the file (and add the needs-lock
>> attribute)
> 
> A parallel situation occurs with ordinary WC merges - in fact it's
> exactly the same situation.  If a user wants to minimize the
> possibility of merge conflicts that she will have to sort through by
> hand, she does 'svn update' before starting a major new feature that
> would be likely to generate such conflicts.  This doesn't guarantee
> anything - her coworker could still commit stuff to the repository
> after she updates - but it reduces the chances of merge problems.  The
> only way to reduce such a chance to zero is to lock the files yourself,
> but I daresay that is usually overkill.

With ordinary "merges" that is expected behavior.  With a locked file,
that is not expected behavior.  In fact, a major reason for locking
support is to deal with files that do not merge well, for example, jpeg
files.  (One could say Word documents too, albeit they are slightly
more mergeable albeit they require domain specific merging tools.)

> Locks are a similar story - in addition to enforcing that the
> repository does not change out from under the user who locks a file,
> they are (or should be) an advisory mechanism (yes, I said "advisory")
> telling other users that they should be careful editing locked files,
> because of an increased chance of merge conflicts later, after the
> files are unlocked.

Re: [l10n] Merging changes from trunk to branch

plasma writes:
 > 
 > I have not been active on translating subverion.po for a long time,
 > and currently I decided to clean the Traditional Chinese version up.
 > 
 > I have done fuzzy messages and new messages on trunk, and commit them
 > back.  But after I ran 'make locale-gnu-po-update' and po-merge.py, I
 > found there are still fuzzy messages.  After reading TRANSLATING file,
 > it says I can translate messages which never existed on trunk, and
 > tweak message options.  But I'm not sure if I can touch fuzzy
 > messages.

Do I understand correctly if I claim that you first ran locale-gnu-po-update
and then po-merge.py on the branch?  If so, and there are still things
that need to be done on the branch, just do them.  I usually commit
after locale-gnu-po-update to improve reviewability of the translation changes.

 > And about the untranslated messages.  I found some of them do exist on
 > trunk, but with a different path, like:
 > 
 >   # 1.3.x Branch
 >   #: clients/cmdline/copy-cmd.c:106 clients/cmdline/delete-cmd.c:64
 >   #: clients/cmdline/mkdir-cmd.c:66
 >   msgid "Local, non-commit operations do not take a log message"
 >   msgstr ""
 >   
 >   # trunk branch
 >   #: svn/copy-cmd.c:108 svn/delete-cmd.c:64 svn/mkdir-cmd.c:66
 >   msgid "Local, non-commit operations do not take a log message"
 >   msgstr "**TRANSLATED MESSAGE**"

RE: [FEATURE]: extend authz algorithm with roles and wildcards to define branch

Re: Automatically reply to group instead of to individual

Edward Harvey writes:
 > Out of curiosity,
 > 
 > Is there any way to automatically reply to the group instead of to
 > individual here, or is that a global setting applied to all users in
 > this group?
 > 

http://subversion.tigris.org/mailing-list-guidelines.html#reply-to

Thanks,
//Peter