FW: svn password -gnome- keyring
Hello,
I have once made a password, after ran `svn udpdate`, it required me for a
password keyring, so I made one.
I noted it somewhere, now it's lost and I can't work with svn anymore because I
can't update anything. (it's not about the project host password).
I exported the working copy to another location, checkout, when update it asked
again.
How could I reset/remove/troubleshoot it?
What is it for, anyway?
Have a great time.
Saudações,
Ivan de Miranda
To: ivang...@hotmail.com
From: supp...@beanstalkapp.com
Subject: Re: I'm confused about how something works
Date: Mon, 4 Jul 2016 13:48:48 +
Hi Ivan,
Thanks for writing in. Hope you had a pleasant weekend. :-)
Unfortunately, I'm no Lubuntu expert, but I did find something that could
explain the dialog box you're seeing.
See:
http://askubuntu.com/questions/184266/what-is-unlock-keyring-and-how-do-i-get-rid-of-it.
It sounds like this is a way to store password and encryption keys. I'd
recommend keeping that password somewhere safe, in case you come across it
again. I hope that helps but please let me know if you have any other questions.
Thanks!
--
Ashley Harpp
Customer Success, Wildbit
Beanstalk, DeployBot, Postmark
How would you rate my reply?
Top NotchFairNot Good
{#HS:222685451-212706#}
On Sun, Jul 3, 2016 at
1:24 PM EDT, Ivan GM wrote:
Hello Beanstalk!
I checked out a beanstalk repository at terminal - on a lubuntu - and inserted
my username and password as usual. When I succeed to do that, prompted a dialog
box with something about a key ring password, don't remember the message. So I
made one and different from my beanstalk password. What is that ? Should I keep
it ? When I will use it again?
Re: A couple thousand mp3 files (this is not spam I swear )
On 8/14/2016 1:22 PM, Adam Jensen wrote: On 08/13/2016 09:33 PM, Branko Čibej wrote: But note that a rename is represented as an add+delete, so the hook would have to be rather smarter than it would seem at first glance to detect and allow renames without content modification. The literal file names are composed of a date and a sequence number, and like the contents of the files, the names should never change. The core data-set directory structure (trunk, maybe) will most likely be calendar-like (years->months->days->sequence->file). The analysis tools and meta-data will probably be kept in a separate fossil[1] repository. [1]: http://www.fossil-scm.org/ The near-term goal is to maintain an indelible record of the physical measurements of reality. Any analysis [of which, there will be plenty], annotations, and other meta-data generation must not alter the fundamental instrumentation data. Given that, by "rename" do you mean a change of the literal file name like what I tried to describe above, or are you referring to something more like the file references, links, or pointers within the repository [internal implementation], similar to David's use of the term "rename" (included below)? Yes, he and I are referring to the same thing. The file contents are not copied, which is your primary goal. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 09:33 PM, Branko Čibej wrote: > There is (currently) no easy way to specify "write once" access for > files in the repository; whoever can create a file can modify or delete > it, too. You could achieve something like that by creating a custom > pre-commit hook that would examine the pending commit transaction and > reject the commit if it finds modifications or deletions of existing files Thanks. I have svnserve configured and ready for a few tests that should enable basic characterization of the system in this use-case. I suppose I could concurrently develop familiarity with the command and operation of this setup while I explore customization of its functioning. Tonight is for contemplation but I imagine testing and hook scripting will begin within the next few days. Does anyone have any comments on using Tcl as a hook scripting language? > But note that a rename is represented as an add+delete, so the hook > would have to be rather smarter than it would seem at first glance to > detect and allow renames without content modification. The literal file names are composed of a date and a sequence number, and like the contents of the files, the names should never change. The core data-set directory structure (trunk, maybe) will most likely be calendar-like (years->months->days->sequence->file). The analysis tools and meta-data will probably be kept in a separate fossil[1] repository. [1]: http://www.fossil-scm.org/ The near-term goal is to maintain an indelible record of the physical measurements of reality. Any analysis [of which, there will be plenty], annotations, and other meta-data generation must not alter the fundamental instrumentation data. Given that, by "rename" do you mean a change of the literal file name like what I tried to describe above, or are you referring to something more like the file references, links, or pointers within the repository [internal implementation], similar to David's use of the term "rename" (included below)? On 08/13/2016 02:21 PM, David Chapman wrote: > On 8/13/2016 11:07 AM, Adam Jensen wrote: >> When a branch is created, are the files under revision control in the >> trunk copied to the branch (is there any duplication of files in the >> repository)? > > No, the files are not copied; a rename is stored. These are "cheap > copies", and this is an advantage over simple backups - if you want to > save history using backups (per another suggestion), you need to retain > one backup per significant event. That can add up.
