Can One Use Subversion for an ecryptfs-protected Subdirectory?
I would like to add an ecryptfs directory as a subdirectory in my unencrypted subversion working directory. I have searched the archives of this list and can find no hits on ecryptfs. Has anyone tried it? Do you check in the directory and files before or after you have mounted the directory as an ecryptfs type? If it is added BEFORE the ecryptfs mount (as I suspect from my experiments), is there any way to inhibit inadvertent updates or commits while the directory is unencrypted? How is that directory handled in the working directory on another host to avoid inadvertent unencrypting? Suggestions and pointers welcome. Thanks. -Tom Thomas M. Browder, Jr. Niceville, Florida USA
Usinh Mercurial with Subversion for Distributed Version Control
This bolg link is a little old: http://blog.red-bean.com/sussman/?p=116 Does anyone have a link to an update or a new solution or recommendation? I would really like to have a copy of my company's subversion repository in some kind of format so that I can use it off line and then push my changes back to the company's repository when it's appropriate. So I am looking for recommendations because I'm ready to jump into this ASAP. Thanks so much. -Tom Thomas M. Browder, Jr. Niceville, Florida USA
Re: Usinh Mercurial with Subversion for Distributed Version Control
On Wed, Sep 15, 2010 at 11:17, Andy Levy wrote: > On Wed, Sep 15, 2010 at 12:14, Tom Browder wrote: ... >> http://blog.red-bean.com/sussman/?p=116 >> >> Does anyone have a link to an update or a new solution or recommendation? >> ... > Does it have to be Mercurial? > http://www.kernel.org/pub/software/scm/git/docs/git-svn.html Thanks, Andy. No, I've just been reluctant to learn git because it seems so foreign to me, an old cvs then subversion user. But I have an open mind. I assume you've had a good experience with the git-subversion model? I think several gcc developers use it, too. Regards, -Tom Thomas M. Browder, Jr. Niceville, Florida USA
Re: Usinh Mercurial with Subversion for Distributed Version Control
On Wed, Sep 15, 2010 at 17:03, Nico Kadel-Garcia wrote: > On Wed, Sep 15, 2010 at 1:00 PM, Tom Browder wrote: >> On Wed, Sep 15, 2010 at 11:17, Andy Levy wrote: >>> On Wed, Sep 15, 2010 at 12:14, Tom Browder wrote: ... >>>> http://blog.red-bean.com/sussman/?p=116 >>>> >>>> Does anyone have a link to an update or a new solution or recommendation? ... >>> Does it have to be Mercurial? >>> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html ... >> I assume you've had a good experience with the git-subversion model? >> I think several gcc developers use it, too. ... > I have, including migration. While I support Subversion in commercial > environments, I'd swap svn for git in a heartbeat for detached > environments, for improved merging, and for *speed*. Thanks, Niko, I appreciate your comments. After looking around some more, bazaar is looking like it works well with my desired work flow (work at home or on the road): 1. company server: subversion repositories (access by vpn--slow and unreliable for a busy developer) 2a. home server: bazaar master repository as a copy of the company subversion repo bazaar repo is backed up to multiple disks regularly bazaar repo changes synched with company subversion repo as able 2b. home server: individual users have clones of bazaar master repo, keep inn sync with master bazaar repo on home server 3. laptop: same as 2b I may not have the terminology exactly correct, but I hope the basic idea shows through. It looks like that is fairly easily doable with bazaar. Regards, -Tom
Re: Usinh Mercurial with Subversion for Distributed Version Control
On Wed, Sep 15, 2010 at 21:07, Nico Kadel-Garcia wrote: > On Wed, Sep 15, 2010 at 6:38 PM, Tom Browder wrote: >> On Wed, Sep 15, 2010 at 17:03, Nico Kadel-Garcia wrote: >>> On Wed, Sep 15, 2010 at 1:00 PM, Tom Browder wrote: >>>> On Wed, Sep 15, 2010 at 11:17, Andy Levy wrote: >>>>> On Wed, Sep 15, 2010 at 12:14, Tom Browder wrote: ... >> 2b. home server: individual users have clones of bazaar master repo, >> keep inn sync with master bazaar repo on home server > > I've not touched that toolkit. I like git because I've found the > svn2git migration easy, the handling of authentication and integrated > GPG signing of authorized tags very helpful, and the merge functions > welcome. The improved centralization control that it lauds is > *precisely* one of the major factors that distributed systems don't > want, but it does have other intersting features. However, both > Subversion and git are supported on my faviorite major open source > repository, sourceforge.net. bazaar is not. > > If you have the chance to try, how well do the bazaar/subversion > integration tools work? I admit that I enjoy being able to work > locally with git, and push and pull upstream as necesasry with the > git-svn toolkits and their proxy like handling for Subversions's. more > broadly supported central repositories. Well, I'm biting the bullet tomorrow. I'll report back later tomorrow or the next day to give you my first impressions. Cheers! -Tom
Using Bazaar with Subversion [WAS Usinh Mercurial with Subversion for Distributed Version Control]
On Wed, Sep 15, 2010 at 21:18, Tom Browder wrote: > On Wed, Sep 15, 2010 at 21:07, Nico Kadel-Garcia wrote: >> On Wed, Sep 15, 2010 at 6:38 PM, Tom Browder wrote: >>> On Wed, Sep 15, 2010 at 17:03, Nico Kadel-Garcia wrote: >>>> On Wed, Sep 15, 2010 at 1:00 PM, Tom Browder wrote: >>>>> On Wed, Sep 15, 2010 at 11:17, Andy Levy wrote: >>>>>> On Wed, Sep 15, 2010 at 12:14, Tom Browder wrote: ... >> If you have the chance to try, how well do the bazaar/subversion >> integration tools work? I admit that I enjoy being able to work >> locally with git, and push and pull upstream as necesasry with the >> git-svn toolkits and their proxy like handling for Subversions's. more >> broadly supported central repositories. > > Well, I'm biting the bullet tomorrow. I'll report back later tomorrow > or the next day to give you my first impressions. Got started but building bazaar resulted in some bazaar pre-requisites' dependency problems with Python 2.7. The I had a gcc building problem...etc. But I have my gcc/Python problem solved and will continue the journey. My first impression is that it's a headache to build bazaar--much better to let the package management people do it--but I think one has to stay on the bleeding edge for bzr-svn. -Tom
Svnadmin —incremental hotcopy (and other questions)
When an incremental hotcopy runs on REPO to BACKUPREPO is BACKUPREPO then always a full backup of REPO? That is, could I do a full dump of BACKUPREPO and copy it somewhere else for safekeeping of the full, current REPO? Another question, is there any reason an incremental hotcopy could not be used in a post commit hook? Finally, now that version 1.10 is out, will the redbook be made current and turned into a printed book? Thanks so much for any help. Best regards, -Tom
Re: Svnadmin —incremental hotcopy (and other questions)
On Tue, Jun 19, 2018 at 06:31 Mark Phippard wrote: > > > On Jun 19, 2018, at 7:25 AM, Tom Browder wrote: ... > > Finally, now that version 1.10 is out, will the redbook be made current > and turned into a printed book? > > The book is open source. It is kept somewhat current but it is a > volunteer effort. I think it is extremely unlikely that O'Reilly would > ever do another printing. Hm, I wonder. I believe it’s been over 10 years since the second edition, and lots of changes. Maybe worth asking O’Reilly? Thanks, Mark. Best regards, -Tom
Hook script common environment variables
The docs mention one can use a common hook environment for multiple repos but so far I can’t find an example of that or any more details. I have looked at the example hook.env file but I don’t see any reference to global env vars. I know I can have each hook script, say as a bash script, source a global file but surely there is a more elegant way to set global variables used by hook scripts. Thanks for any help. Best regards, -Tom
Re: Hook script common environment variables
On Wed, Jun 20, 2018 at 03:02 Stefan Sperling wrote: > > On Tue, Jun 19, 2018 at 06:39:09PM -0500, Tom Browder wrote: > > > The docs mention one can use a common hook environment for multiple repos > > but so far I can’t find an example of that or any more details. I have > > looked at the example hook.env file but I don’t see any reference to global > > env vars. > > It is unclear which type of server are you using. > Apache HTTPD with mod_dav_svn, or svnserve? > > For svnserve, you can specify a path in svnserve's config file: > [general] > hooks-env = /path/to/a/global/hooks-env/file Okay, that’s part of what I was looking for. I am using svnserve. However, according to "man svnserve" I am using it not as a daemon but with svn+ssh so I have to specify the global file explicitly somehow. But I can add that common path in each repo’s hook-env, that’s clear. > The environment specified in the referenced file will then apply I think that only applies to the daemon as I read the docs. > to all repositories. The referenced file's syntax is shown in the > hook.env example you've already found. That referenced example is for an individual repo. But if it is true for svn+ssh, does one just drop a svnserv.conf file in directory /etc/subversion.? > Could you please point us at the docs you were reading which were > unclear? Maybe they need to be adjusted or updated. Thanks. I’ll send doc suggestions after I get a working solution (PRs accepted?). Thanks, Stefan. Best regards, -Tom
Old repo backup, checkout current, lost repo, create new repo?
I have three svn repos I recently (6 months ago) moved to my private, remote server. Due to life and negligence, I only have one svn hotcopy of two of them made immediately after the move. A week ago the disk with the three repos failed. I have current copies of each repo’s trunk (I’m not not using branches) and want to know the best way to get the repos back in place and working again. I am the only user, and I use the svn+ssh access to the repo completely owned by myself. History is not terribly important. >From what I can find in various docs, I think the easiest way to recover is to copy the 6-month-old hot copy to the original path and resume working from there as usual (plus make sure my backups work in the future!). For the other I will just recreate the repo from scratch. Given that history will be lost, does anyone see any problems with my recovery plan? Thanks for any advice. Best regards, -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia wrote: > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: ... > > Given that history will be lost, does anyone see any problems with my > > recovery plan? ... > If you have working copies and you don't care about history, why are > you spending any cycles on doing anything with hotcopy? You've lost > history anyway, why keep any of it? Cycles aren't important, but the size of the data is. Transferring the working copy from scratch would take a LONG time, while the bulk of the data are already there in the hotcopy. So, again, would my plan work to re-establish my repo and work flow? Thanks. -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 4:55 AM Tom Browder wrote: > > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia wrote: > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder wrote: > ... > > > Given that history will be lost, does anyone see any problems with my > > > recovery plan? > ... > > If you have working copies and you don't care about history, why are > > you spending any cycles on doing anything with hotcopy? You've lost > > history anyway, why keep any of it? ... > So, again, would my plan work to re-establish my repo and work flow? Ping? I really need some expert opinion here so I can proceed: is my plan to replace the lost repos with their hotcopies okay? Thanks. -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 15:56 Stefan Sperling wrote: ... Thank you, Stefan! Best regards, -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 19:45 Nico Kadel-Garcia wrote: > On Mon, Dec 10, 2018 at 5:56 AM Tom Browder wrote: > > > > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia > wrote: > > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder > wrote: > > ... > > > > Given that history will be lost, does anyone see any problems with > my recovery plan? > > ... > > > If you have working copies and you don't care about history, why are > > > you spending any cycles on doing anything with hotcopy? You've lost > > > history anyway, why keep any of it? > > > > Cycles aren't important, but the size of the data is. Transferring the > > working copy from scratch would take a LONG time, while the bulk of > > the data are already there in the hotcopy. > > Under what possible conditions wound importing a single snapshot of > the current working copy, without history, take more time than working > from a hotcopy to overlay the changes on top of that hotcopy? I don’t know, Nico, I am a real novice at this. Your first answer didn’t help because I didn’t know the ramifications of what I was trying to do. The original data, from just six months ago, was about 27 Gb, which took a very long time to upload from my home computer to my remote server. Since the only hotcopy, done shortly after the repo was loaded, there has been very little change, so if I could start with the hotcopy and somehow synch my working copy without pushing 27 Gb again, life would be better. Howver, it sounds like there is no way around a massive upload again :-( Thanks. -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Mon, Dec 10, 2018 at 23:15 Nico Kadel-Garcia wrote: > > On Mon, Dec 10, 2018 at 9:10 PM Tom Browder wrote: > > > > > > > > On Mon, Dec 10, 2018 at 19:45 Nico Kadel-Garcia wrote: > >> > >> On Mon, Dec 10, 2018 at 5:56 AM Tom Browder wrote: > >> > > >> > On Mon, Dec 10, 2018 at 12:10 AM Nico Kadel-Garcia > >> > wrote: > >> > > On Sun, Dec 9, 2018 at 6:31 PM Tom Browder > >> > > wrote: > >> > ... > >> > > > Given that history will be lost, does anyone see any problems with > >> > > > my recovery plan? > >> > ... > >> > > If you have working copies and you don't care about history, why are > >> > > you spending any cycles on doing anything with hotcopy? You've lost > >> > > history anyway, why keep any of it? > >> > > >> > Cycles aren't important, but the size of the data is. Transferring the > >> > working copy from scratch would take a LONG time, while the bulk of > >> > the data are already there in the hotcopy. > >> > >> Under what possible conditions wound importing a single snapshot of > >> the current working copy, without history, take more time than working > >> from a hotcopy to overlay the changes on top of that hotcopy? > > > > > > I don’t know, Nico, I am a real novice at this. Your first answer didn’t > > help because I didn’t know the ramifications of what I was trying to do. > > > > The original data, from just six months ago, was about 27 Gb, which took a > > very long time to upload from my home computer to my remote server. Since > > the only hotcopy, done shortly after the repo was loaded, there has been > > very little change, so if I could start with the hotcopy and somehow synch > > my working copy without pushing 27 Gb again, life would be better. > > ??? An import of the copy of the working data has no history. Is the > *data* 27 GB, with no .svn content, 27 GB ? What in the devil are you > putting in source control? > > I'm not objecting to your situation, just really confused by the > content you are dealing with. Sorry, Nico, I probably didn’t use the correct terms in my problem description. Basically the subversion repos on my remote server were current as of about six months ago when they were established there and a hotcopy was made. There have been few updates since, so is the hotcopy of value or not, history wise? Anyway, my thought was to save some upload and download time if possible. UPDATE: Problems in svn-repo land I copied the two hotcopy backups to the original repo locations, and my local server has found them (I'm using GUI client SmartSVN on Windows, command line on Linux). I started to update on one and am getting these messages (which you warned me about): Clean Up: Failed to run the WC DB work queue associated with 'C:\Users\Tom\Documents\0-mydocs-svn', work item 636 (file-install Personal/TomB/sto/Misc/llftpar2.exe 1 0 1 1) Can't open file 'C:\Users\Tom\Documents\0-mydocs-svn\.svn\pristine\7e\7eddb1479c338c0a0fb4a08e21e2b81a8d6c1b61. svn-base': The system cannot find the file specified. FWIW, the repos are on my remote Linux server I have full control over--running Debian 9. (Note the working copy is on Windows, and I do not have a wc of it on my local Linux host.) Is there anything I can do to fix something like that? Or do I have to go through creating new repos and populating them from he original repo files and dirs? Thanks so much. -Tom
Re: Old repo backup, checkout current, lost repo, create new repo?
On Fri, Dec 14, 2018 at 5:26 AM Stefan Sperling wrote: > On Thu, Dec 13, 2018 at 07:18:23AM -0600, Tom Browder wrote: ... > > description. Basically the subversion repos on my remote server were > > current as of about six months ago when they were established there > > and a hotcopy was made. > > You should reconsider your backup strategy. ... > a different physical machine. Use the post-commit hook to trigger a backup > (and the post-revprop-change hook, too, if your repository is configured > to allow revprop changes). ... I was in the process of setting that up and got distracted (old age :-). > Only you can decide whether the history of your data is valuable to you. True. > > I started to update on one and am getting these messages (which you > > Clean Up: Failed to run the WC DB work queue associated with > > 'C:\Users\Tom\Documents\0-mydocs-svn', work item 636 (file-install ... > This error means the working copy is corrupt. This error has nothing to do > with the repository. The working copy's work queue contains instructions to > copy a temporary file into the area where you see the files you work with. ,,, > Generally, SVN's design considers working copies as disposable > because they can always be checked out again, Your resistence to > transferring your data again is working against that design assumption. I'm guilty as charged! > > Is there anything I can do to fix something like that? Or do I have ... > heard about last Sunday. Would it take you more than a week to transfer > the data? Maybe you should just do something that allows you to move on, > instead of waiting until you find a potentially perfect solution? Yes, I made some bad decisions. Many thanks, Stefan! -Tom
Svn 1.8.3 error: E200007
I have just today started using the svn merge command to update my private branch from a remote repo trunk on Sourceforge. In my branch work dir I execute: $ svn merge ^/brlcad/trunk . and the response is: svn: E27: Retrieval of mergeinfo unsupported by 'svn+ssh:// tbrowd...@svn.code.sf.net/p/brlcad/code/brlcad/branches/attr-extension-mods' I see some mail in the archives about the same error number but not the exact same command. I am using old (but legit) Debian apr and apr-util libraries but I am using the latest serf embedded with the svn source (./get-deps.sh). Note the "old" way does work: $ svn merge ^/brlcad/trunk -r57266:HEAD but keeping track of the revs is a real pain. Should I file a bug? (I got the same error with ver 1.8.1.) Best regards, -Tom
Re: Svn 1.8.3 error: E200007
On Sat, Aug 31, 2013 at 11:36 AM, Branko Čibej wrote: > On 31.08.2013 18:23, Tom Browder wrote: > > svn: E27: Retrieval of mergeinfo unsupported by > > 'svn+ssh:// > tbrowd...@svn.code.sf.net/p/brlcad/code/brlcad/branches/attr-extension-mods > > < > http://tbrowd...@svn.code.sf.net/p/brlcad/code/brlcad/branches/attr-extension-mods > >' > >Your problem is that either the server is too old, or the repository > format is too old to support mergeinfo. Most likely the repository was > created by a version of svnadmin older than 1.5, and never upgraded. See: > The Sourceforge server is using ver 1.7.7. Note that I'm using the svn+ssh protocol. I'll try the https and see if that makes a difference. Best, -Tom
Re: Svn 1.8.3 error: E200007
On Sat, Aug 31, 2013 at 1:06 PM, Branko Čibej wrote: > On 31.08.2013 19:18, Tom Browder wrote: > > The Sourceforge server is using ver 1.7.7. > > Note that I'm using the svn+ssh protocol. I'll try the https and see if > that makes a difference. > > > The protocol, and even the server version, aren't that important (although > obviously the server has to be 1.5 or newer). The point is that the > repository was created with 1.4 or older, and never upgraded. > Ah! Thanks, Brane. Is there any way to check a repo format version? -Tom
