On Fri, 25 Oct 2013 18:35:22 +0200, Tomek Kott <tkott.onl...@outlook.com>
wrote:
I thought I noticed the same effect, but at the time I chalked it up to
not restarting the UI/server between changing the default name and
playing around the UI. I noticed it only because the log-in name was
substantially longer, and so it popped out at me as being out of place.
Could this be the case for you?
no. the UI was not running when I set the new default user. but when I
start
it, it always pops up stating "logged in as {userid}' where `userid' is the
id under which the initial clone was done. and `userid' is then what is
used
by the UI for tickets and wiki edits. the CLI checkins on the other hand
end
up as being listed with the "default user" setting.
I also changed the capabilities of the new default user to "s" but that
makes no
difference.
I'm now trying to think that changing the capabilities of the original
clone user to 'a' from 's' was what solved the problem. Something about
too many 's' users perhaps?
no, not too many 's' users (only the "clone user"). but you are right: the
problem is related to this:
one has to remove the 's' capability for the "clone user" +and+ give the
's' capability to the new
default user. at that point the message changes to "logged in as
{localname}" where `localname' is
the defined default user.
if one does _not_ provide the 's' it becomes "logged in as ?" (verbatim)
and the user `?' is
listed in the timeline as ticket creator, e.g. mmmh.....
a big thanks, anyway, for providing me with this hint how to workaround
the issue.
the question to the developer(s) would be: is the present behaviour
"natural" from some higher perspective? or is it really an inconsistency
that should/could be fixed? by the way, the use case I have in mind is,
where several working groups each get a generic userid for cloning/login
to the server repo, but where members of the groups might change over time
(so it does not make too much sense to keep creating new userids for each
and every single person in the central repo). my idea now was to propose
to that each group member to clone using the generic userid of his group
and then to create locally his own "default user" (using his actual name
or whatever scheme is preferred) and to commit and submit tickets under
that local id.
Tomek
(Sorry if this is broken up, I'm responding to a digest)
recently, a (desirable) change was introduced that after
fossil clone http://userid@server/repo myclone.fossil
the local default user is set to `userid' instead of the local user
name,
which is usually the preferred behavior in my view. however, sometimes
it
is still desirable to have a different local default user (be it the
local
user account name or full name). in this situation I see the following
behaviour:
after the above clone operation plus
fossil user new localname
fossil user default localname
all commits appear in the timeline with user "localname" (as they
should).
however, tickets and wiki changes appear in the timeline as coming from
user `userid' (i.e. the user having done the clone).
I would think that the "default user" setting should be respected here,
too, or am I mistaken?
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
