On Thu, 08 Aug 2013 09:53:52 +0200, Andy Bradford <amb-sendok-1378540432.bggbdoanfmpdfnjoo...@bradfords.org> wrote:

Thus said "j. van den hoff" on Thu, 08 Aug 2013 09:31:28 +0200:

1.    in   `orig.fossil'    the    (sole)   `setup'    user   is    me
(current_login_name), which is as it should be. (as an aside: the help
text does  speak of `admin'  user, but  actually its the  `setup' user
(and a `admin' user has  different (somewhat lower) permissions) -- so
this might call for a change of the help text?)

Minor issue but should probably be clarified.

sure minor but a question of consistency. the option is even named `--admin-user'.
easiest way to "fix" it might be a different naming scheme in the GUI

setup user --> admin user
admin user --> whatever


2. but in `clone.fossil' the web interface tells me that there are two
`setup' users: current_login_name and JoeDoe

question: should  I expect this (I  did not...)? I would  have thought
that there  will be  a single one  (JoeDoe). and that  is also  what I
intend to get...

Either the text is wrong, or the  behavior is wrong. One of them must be
fixed. I believe it is not creating  a new user that matches your login,
but rather  is preserving  the user  that exists  in the  source fossil,

yes, that's probably the case.

perhaps it is related to this comment I made:

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12524.html
You are doing a file clone.  Other types of cloning do not do this:

$ fossil clone -A someone ssh://remote//tmp/test.fossil new.fossil
...
project-id: 78f3c64bd97f33cb0a7606842ca83ddf25776819
admin-user: someone (password is "2c9149")
$ fossil user -R new.fossil list
anonymous    Anon
developer    Dev
nobody       Nobody
reader       Reader
someone

I see. I would argue that the file system based clone should behave the same: if I explicitly specify a non-default admin-user that should be the exclusive one after in the clone.


... if  I don't  care that  the locally used  user names  are becoming
known and the passwords are  irrelevant/not valuable either: are there
any  more points  to  consider, i.e.  is there  anything  else in  the
database which one should not distribute just so?

Email addresses. Private branches in the repository. IP addresses. There
is an option to scrub the fossil of sensitive info.

fossil help scrub

thanks for this tip. I was not aware of that.

j.

Andy


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

Reply via email to