Re: prevent Linux root from seeing my files

2010-11-30 Thread Daniel Shahaf 
Chris Albertson wrote on Mon, Nov 29, 2010 at 11:29:39 -0800:
 Absolutely  NOTHING will work if a person has physical access to the
 server.

+1, with the exception of versioning encrypted files.

(and we have diff-cmd and such in the config file, which can be used to
make 'diff' be useful)

Re: svnsync and new auth realm

2010-11-30 Thread Daniel Shahaf 
Just run the svnsync manually once and have it save the password in the
config dir.

Christian Unger wrote on Mon, Nov 29, 2010 at 13:03:17 +0100:
 
 
 so I have changed the authentication realm of my repository - this rather 
 small change causes apache to make users re-authenticate against this realm.
 
 now my buildbot triggered svnsync task fails because of this realm change - 
 despite the fact that I tell it to always trust the server certs and friends 
 - because I obviuosly have to also re-authenticate my sync task.
 
 I understand that I could specify the credentials on the command line but I 
 do hesitate because buildbot outputs the task's status to the log.
 
 Is there a smarter way to let the sync'ed repository know how to authenticate 
 against the source repository?
 
 
 thx in advance
 __
 cu
 christian unger

Re: prevent Linux root from seeing my files

2010-11-30 Thread Campbell Allan 

On Monday 29 Nov 2010, Piotr Kabaciński wrote:
 On 11/29/2010 12:50 PM, Campbell Allan wrote:
  If you are able to create dedicated partition you could encrypt repo
  like described here:
  http://www.hypersphere.org/personal/svn.shtml
 
  With some pretty important drawbacks, the no diff/conflict resolution
  would be a dealbreaker for me

 With encryption on filesystem level files in repo are not saved as
 binary (in terms of svn). Svn with repo works like it works before.
 Drawback is that OS has to compress and decompress file every time you
 need to commit/checkout.
 Diff would be useless if you encrypt every file before commit, and send
 it as binary, and that is not this situation.

 greetings


I'm going to have to reread the page but those points were taken from the 
author of the web page and are not my own.

My understanding is that subversion operations are applied on the working copy 
but edits must be done within the FUSE mountpoint of the working copy that 
decrypts and encrypts the files. Therefore diff does not work as this is done 
on the encrypted version of files. If a diff was tried from within the FUSE 
mountpoint then the pristine copies of files would now be decrypted to 
something completely different than expected.

The upside is that the repository contents *are* secure as everything sent to 
the repository is encrypted, the problem is that it severely cripples the 
features of subversion and it might be just as good to use a local repository 
and back it up (with encryption) to the remote server.

  * The svn diff command is rendered useless, as the repository itself is
  comprised, entirely, of encrypted data.
  * The repository will be enormous. Because the data is all encrypted with
  a block cipher, Subversion will be incapable of efficiently storing
  diffs, and compression programs (such as BZip) will, also, have little
  effect. A few basic tests have shown a 300% increase in repository size,
  making it wise to restrict the amount of data stored therein.
  * Conflict-resolution via subversion will also be useless. If a conflict
  occurs, you'll have to manually merge the two versions on the mountpoint.


-- 

__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__

RE: AW: How to find out the rev number where a file was deleted?

2010-11-30 Thread Ludwig, Michael 
 -Original Message-
 From: Les Mikesell
 On 11/29/2010 11:45 AM, Ludwig, Michael wrote:

  I can see that from the peg rev point of view, HEAD is the
  future. But I think we can also agree that from the SVN user's
  perspective, every single existing rev including HEAD is in
  the past.
 
 Yes, but from the perspective of getting history where you can
 only go backwards, you have to specify the right starting point,
 and a rev where the thing doesn't exist isn't the right place.

Certainly. Just imagine you weren't required to specify a revision:

svn show svn://server.dev/eins/zwei/drei/vier.txt

 seq node-id  revision  status
   1 1bca34933  A
   1 1bca34975  M
   1 1bca34976  M
   1 1bca349   111  M
   1 1bca349   188  D
   2 4941b20  1099  A
   2 4941b20  1101  M
   2 4941b20  1108  M
   2 4941b20  1831  D
   3 6e6cdff 18004  A
   3 6e6cdff 18014  M

The node ID would identify the versioned object. (I don't know
anything about what the node ID might look like; the example is
just a wild guess.) This sketch certainly has flaws, but is it an
unreasonable proposal? Users might find it useful.

  Yes, there could be several items - several revision ranges -
  in the index, pointing to several unrelated objects. But is it
  a big problem?
 
 Yes, if you are in the habit of deleting things and adding them
 back, then wanting one of the deleted versions.

You'd read it from the list and identify it by revision. No
changes to existing behaviour and functionality.

  In database speak, we'd indeed have a compound key for
  *uniquely* identifying an object, with the first part of that
  compound key being the URL, and the second part the revision.
  But if we don't know the revision, we simply use the URL alone
  and receive a list of all the items ever to have appeared at
  that URL. Which ones we're interested in is then a matter of
  human decision; but gone is the tedium (or wasteful scanning)
  of establishing the list in the first place.
 
 That's a reasonable thing to want, but perhaps not reasonable
 for the server to deliver. Would you expect your database to
 find things for you if you renamed or deleted the table holding
 them?

I wouldn't. But if I had a trigger to log changes made to a table
to a log table I'd expect the system to know the table history.
That's maybe a bit more aligned with what I might expect from a
version control system.

  A thing with the same name added later as a replacement may
  have nothing in common with the item you want. I'm not sure
  what the right test for this would be other than asking for a
  log with a rev range and a peg rev to anchor it to one
  specific version.
 
  Give me a listing of the things and either require me to
  specify which one I want or show them all in full detail,
  depending on the circumstances. In the special case where
  there is only one item in the list, no further precision is
  needed.
 
 It's a big order to make that happen through a client-server
 connection that has no such existing concept and no server side
 hints to do it efficiently.

I agree the server side needs to have the URL index to do it
efficiently. Given that index, however, it shouldn't be difficult.
I wouldn't redesign the existing set of commands, just provide
one in addition that provides the history of a URL.

Best,

Michael

RE: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

2010-11-30 Thread Engebakken Geir 
I must be missing something here, is this patch applied to the current SVN 
source?

I have downloaded SVN 1.6.15 source from Tigris.org, and cant find the changes 
in the source. Also this patch is applied to a file : subversion/svnsync/sync.c 
but in my downloaded source there is only a file main.c in the svnsync 
directory.

We are for the moment stuck with this UTF-8 problem in one of our svn:ignore 
properties, and cant proceed with seting up this sync, so any pointers are 
welcome!



Geir

Note : All inquiries regarding Subversion, MKS and general Development servers 
should be directed to EDB SourceControl System


 -Original Message-
 From: Daniel Trebbien [mailto:dtrebb...@gmail.com]
 Sent: 9. september 2010 17:49
 To: Daniel Shahaf
 Cc: users@subversion.apache.org; d...@subversion.apache.org
 Subject: Re: svnsync failure when syncing with a repository that used
 ISO-8859-1 for log messages
 
 On Thu, Sep 9, 2010 at 3:48 AM, Daniel Shahaf d...@daniel.shahaf.name
 wrote:
  CC += dev@, and let me point you to our patch submission guidelines:
  http://subversion.apache.org/docs/community-
 guide/general.html#patches
 
  Summary for dev@: allow svnsync to translate non-UTF-8 log messages
 to UTF-8.
 
  (more below)
 
  Daniel Trebbien wrote on Wed, Sep 08, 2010 at 18:58:06 -0700:
  On Wed, Sep 8, 2010 at 4:39 PM, Daniel Trebbien
 dtrebb...@gmail.com wrote:
   I think that a call to `svn_subst_translate_string`
   (http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) needs
 to be
   added in the `svnsync_normalize_revprops` function when `propname`
 is
   svn:log.
 
  After applying the following patch to `subversion/svnsync/sync.c`, I
  can confirm that the svnsync: Error while replaying commit error
  disappears, allowing the sync to complete, and that the problem is
  indeed a log message encoding issue:
  diff --git a/subversion/svnsync/sync.c b/subversion/svnsync/sync.c
  index 8f7be9e..c7a5e38 100644
  --- a/subversion/svnsync/sync.c
  +++ b/subversion/svnsync/sync.c
  @@ -114,6 +114,14 @@ svnsync_normalize_revprops(apr_hash_t
 *rev_props,
                 /* And count this. */
                 (*normalized_count)++;
               }
  +
  +          if (strcmp(propname, svn:log) == 0)
  +            {
 
  Should this use svn_prop_needs_translation()?
 
 Though it does not appear so, the added lines are within the check for
 `svn_prop_needs_translation`.
 
  +              svn_string_t *new_propval;
  +              SVN_ERR(svn_subst_translate_string(new_propval,
 propval, ISO-8859-1, pool));
  +              apr_hash_set(rev_props, propname,
 APR_HASH_KEY_STRING, propval = new_propval);
 
  Please, please, please, no assignment inside a function call.
   ^
 
 Fixed
 
  +              (*normalized_count)++;
  +            }
           }
       }
     return SVN_NO_ERROR;
 
 
  Here I hard-coded the encoding, but I think that the encoding to use
  should be retrieved from the Subversion config file. Now the
 questions
  are:
 
  1. What is the best way to pass the `log-encoding` option of the
  [miscellany] section to the `svnsync_normalize_revprops` function?
 
 
  What is 'log-encoding' normally used for?  Only for recoding the
 commit
  message supplied by an editor, right?  So I'm not sure we should use
 it
  here, perhaps a new command-line option will be better.  (svnsync
  $subcommand --source-encoding=%s)
 
 I like the idea of adding a command line option, so I think that this
 is the way to go.
 
 Do other properties need to be re-encoded, potentially? I was only
 thinking about `svn:log`, but perhaps other properties might need
 re-encoding as well. If not, then I think that the command line option
 should be more specific (e.g.: `--source-log-encoding=%s`).
 
  And either way, the default behaviour should be to translate nothing.
  (If you always translate from latin1, you break syncs for people who,
  correctly, used UTF-8 log messages the entire time.)
 
 I agree. The default behavior should definitely be to not re-encode
 the log messages.
 
  2. Should `svnsync` always store the log messages in UTF-8 even
 though
  the original repository log message encoding is different?
 
 
  You have no choice on the matter: the RA API instructs you to supply
 it
  a UTF-8 log message.  (IIRC, even the libsvn_client API expects an
  already-UTF-8 message.)
 
  3. Should there be separate configuration options for the log
 message
  encoding of the source repository and the log message encoding of
 the
  destination repository?
 
  No, see (2).
 
 
 Another question:  which line of code raises the svnsync: Error while
 replaying commit error message? I would like to try to make this more
 helpful.

Re: How to find out the rev number where a file was deleted?

2010-11-30 Thread Andrey Repin 
Greetings, Les Mikesell!

 Still, this should at least produce some results:  (as long as foo existed
 in rev 3)
   svn log -r 0:head file://${HOME}/trash/repo/f...@3
   svn: File not found: revision 5, path '/foo'
 It makes no sense for svn to complain about what's in rev 5.  My query
 doesn't care about rev 5.

 I think the principle was covered in another response, but the only way 
 you can get history is to start from the highest rev and follow 
 backwards, and you are asking it to start from head, which is impossible.

Impossible within current realization of storage backend. But sensible from
user's viewpoint and scheduled to be resolved in future.
I'd ask you to stop giving out your own opinion under mask of absolute truth.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 30.11.2010, 16:36

Sorry for my terrible english...

RE: Subversion Authentication

2010-11-30 Thread Patrick Brennan 
We installed Subversion on a Windows 2003 Standard SP2 Server box.
Installed from exe file downloaded from website.
Chose windows authentication and created top level repository.
We know nothing about this software as it was just dumped in our laps so sorry 
about the lack of useful information.

Thanks
 
Patrick J. Brennan
ZAIS Group, LLC
2 Bridge Avenue, Suite 322
Red Bank, New Jersey 07701
Phone: (732) 450-7445
patrick.bren...@zaisgroup.com


-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: Monday, November 29, 2010 7:32 PM
To: Patrick Brennan
Cc: users@subversion.apache.org; Stephen Epstein
Subject: Re: Subversion Authentication

On Mon, Nov 29, 2010 at 2:42 PM, Patrick Brennan
patrick.bren...@zaisgroup.com wrote:
 Hello,



 We have a default install of Subversion software and our users are
 requesting Authentication be setup for our Developers Domain group and a
 Domain group in another sister domain.

What is a default install? A Linux box with RPM's from RPMforge, a
Windows server with a particular toolkit, or what?

Any Apache based server that can handle mod_auth_kerb can use the
underlying Kerberos login names and passwords that Active Directory is
built on. That doesn't get you group management, but it's a starting
place. Be aware that Linux and UNIX and CygWin svn command line
clients, by default, will store the HTTP or HTTPS passwords in clear
text in the user's home directory: this is why I generally refuse to
use this.

But if you can somehow prevent such access, or have confidence in your
users not to use such tools, it should be straightforward to set up.
Group information and privileges, well, you'd have to give better
ideas of what you're trying to allow, and what you're trying to
prevent. And you *really* need to go read the Subversion book at
http://svnbook.red-bean.com/, focusing on the access control chapters.
Especially look here:
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd.authn

 We have no idea how to do this to disable everyone from having access which
 they do now and only give access to select domain groups.

 Any help would be appreciated.
 


This e-mail message is intended only for the named recipient(s) above. It may 
contain confidential information. If you are not the intended recipient you are 
hereby notified that any dissemination, distribution or copying of this e-mail 
and any attachment(s) is strictly prohibited. If you have received this e-mail 
in error, please immediately notify the sender by replying to this e-mail and 
delete the message and any attachment(s) from your system. Thank you.

This is not an offer (or solicitation of an offer) to buy/sell the 
securities/instruments mentioned or an official confirmation. This is not 
research and is not from ZAIS Group but it may refer to a research 
analyst/research report. Unless indicated, these views are the author's and may 
differ from those of ZAIS Group research or others in the Firm. We do not 
represent this is accurate or complete and we may not update this. Past 
performance is not indicative of future returns.

 
IRS CIRCULAR 230 NOTICE:.

 
To comply with requirements imposed by the IRS, we inform you that any U.S. 
federal tax advice contained herein (including any attachments), unless 
specifically stated otherwise, is not intended or written to be used, and 
cannot be used, for the purpose of (i) avoiding penalties under the Internal 
Revenue Code or (ii) promoting, marketing or recommending any transaction or 
matter addressed herein to another party.  Each taxpayer should seek advice 
based on the taxpayer's particular circumstances from an independent tax 
advisor.

ZAIS, ZAIS Group and ZAIS Solutions are trademarks of ZAIS Group, LLC.

Re: Subversion Authentication

2010-11-30 Thread Andy Levy 
On Tue, Nov 30, 2010 at 08:43, Patrick Brennan
patrick.bren...@zaisgroup.com wrote:
 We installed Subversion on a Windows 2003 Standard SP2 Server box.
 Installed from exe file downloaded from website.

What website? I can think of at least 3 distributions of Subversion
built for Windows  packaged into an installer.

 Chose windows authentication and created top level repository.
 We know nothing about this software as it was just dumped in our laps so 
 sorry about the lack of useful information.


You might want to talk to the people who dumped it in your laps too.


 -Original Message-
 From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
 Sent: Monday, November 29, 2010 7:32 PM
 To: Patrick Brennan
 Cc: users@subversion.apache.org; Stephen Epstein
 Subject: Re: Subversion Authentication

 On Mon, Nov 29, 2010 at 2:42 PM, Patrick Brennan
 patrick.bren...@zaisgroup.com wrote:
 Hello,



 We have a default install of Subversion software and our users are
 requesting Authentication be setup for our Developers Domain group and a
 Domain group in another sister domain.

 What is a default install? A Linux box with RPM's from RPMforge, a
 Windows server with a particular toolkit, or what?

 Any Apache based server that can handle mod_auth_kerb can use the
 underlying Kerberos login names and passwords that Active Directory is
 built on. That doesn't get you group management, but it's a starting
 place. Be aware that Linux and UNIX and CygWin svn command line
 clients, by default, will store the HTTP or HTTPS passwords in clear
 text in the user's home directory: this is why I generally refuse to
 use this.

 But if you can somehow prevent such access, or have confidence in your
 users not to use such tools, it should be straightforward to set up.
 Group information and privileges, well, you'd have to give better
 ideas of what you're trying to allow, and what you're trying to
 prevent. And you *really* need to go read the Subversion book at
 http://svnbook.red-bean.com/, focusing on the access control chapters.
 Especially look here:
 http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd.authn

 We have no idea how to do this to disable everyone from having access which
 they do now and only give access to select domain groups.

 Any help would be appreciated.

 

 This e-mail message is intended only for the named recipient(s) above. It may 
 contain confidential information. If you are not the intended recipient you 
 are hereby notified that any dissemination, distribution or copying of this 
 e-mail and any attachment(s) is strictly prohibited. If you have received 
 this e-mail in error, please immediately notify the sender by replying to 
 this e-mail and delete the message and any attachment(s) from your system. 
 Thank you.

 This is not an offer (or solicitation of an offer) to buy/sell the 
 securities/instruments mentioned or an official confirmation. This is not 
 research and is not from ZAIS Group but it may refer to a research 
 analyst/research report. Unless indicated, these views are the author's and 
 may differ from those of ZAIS Group research or others in the Firm. We do not 
 represent this is accurate or complete and we may not update this. Past 
 performance is not indicative of future returns.


 IRS CIRCULAR 230 NOTICE:.


 To comply with requirements imposed by the IRS, we inform you that any U.S. 
 federal tax advice contained herein (including any attachments), unless 
 specifically stated otherwise, is not intended or written to be used, and 
 cannot be used, for the purpose of (i) avoiding penalties under the Internal 
 Revenue Code or (ii) promoting, marketing or recommending any transaction or 
 matter addressed herein to another party.  Each taxpayer should seek advice 
 based on the taxpayer's particular circumstances from an independent tax 
 advisor.

 ZAIS, ZAIS Group and ZAIS Solutions are trademarks of ZAIS Group, LLC.

Re: AW: How to find out the rev number where a file was deleted?

2010-11-30 Thread Les Mikesell 

On 11/30/10 5:21 AM, Ludwig, Michael wrote:




I can see that from the peg rev point of view, HEAD is the
future. But I think we can also agree that from the SVN user's
perspective, every single existing rev including HEAD is in
the past.


Yes, but from the perspective of getting history where you can
only go backwards, you have to specify the right starting point,
and a rev where the thing doesn't exist isn't the right place.


Certainly. Just imagine you weren't required to specify a revision:

svn show svn://server.dev/eins/zwei/drei/vier.txt

  seq node-id  revision  status
1 1bca34933  A
1 1bca34975  M
1 1bca34976  M
1 1bca349   111  M
1 1bca349   188  D
2 4941b20  1099  A
2 4941b20  1101  M
2 4941b20  1108  M
2 4941b20  1831  D
3 6e6cdff 18004  A
3 6e6cdff 18014  M

The node ID would identify the versioned object. (I don't know
anything about what the node ID might look like; the example is
just a wild guess.) This sketch certainly has flaws, but is it an
unreasonable proposal? Users might find it useful.


But the name has nothing to do with the versioning of the object.  Names appear 
in the directory containing it.  The object itself might have a different name 
every revision if the modifications are moves.  Or the same name might be a 
different object with deletes followed by adds or copies to the name in 
question.  Subversion only tracks the object itself using the name to identify a 
starting point.  But you can see the names come and go in the history of the 
directories containing them.



Yes, there could be several items - several revision ranges -
in the index, pointing to several unrelated objects. But is it
a big problem?


Yes, if you are in the habit of deleting things and adding them
back, then wanting one of the deleted versions.


You'd read it from the list and identify it by revision. No
changes to existing behaviour and functionality.


Where does the client/server protocol have such functionality now?  I think it 
is only in showing a log -v of the directory containing the name.



I wouldn't. But if I had a trigger to log changes made to a table
to a log table I'd expect the system to know the table history.
That's maybe a bit more aligned with what I might expect from a
version control system.


You have that in the versioning of the directory where the name appears.


It's a big order to make that happen through a client-server
connection that has no such existing concept and no server side
hints to do it efficiently.


I agree the server side needs to have the URL index to do it
efficiently. Given that index, however, it shouldn't be difficult.
I wouldn't redesign the existing set of commands, just provide
one in addition that provides the history of a URL.


That already exists.  A 'log -v' from the top of the repo will show all deletes 
and adds ever done.  The output isn't convenient to feed to grep, etc., though.


--
  Les Mikesell
   lesmikes...@gmail.com

RE: Subversion Authentication

2010-11-30 Thread Patrick Brennan 
This is from the readme file

VisualSVN Server 2.1.4
--

VisualSVN Server is a package that contains everything you need to install,
configure and manage Subversion server for your team on Windows platform. It
includes Subversion, Apache and a management console.

This distribution contains the following components:
- Subversion 1.6.13
- Apache 2.2.13
- OpenSSL 0.9.8l
- ZLib 1.2.3
- Neon 0.29.3

For more information please visit http://www.visualsvn.com/server/

Thanks
 
Patrick J. Brennan
ZAIS Group, LLC
2 Bridge Avenue, Suite 322
Red Bank, New Jersey 07701
Phone: (732) 450-7445
patrick.bren...@zaisgroup.com


-Original Message-
From: Andy Levy [mailto:andy.l...@gmail.com] 
Sent: Tuesday, November 30, 2010 8:48 AM
To: Patrick Brennan
Cc: users@subversion.apache.org
Subject: Re: Subversion Authentication

On Tue, Nov 30, 2010 at 08:43, Patrick Brennan
patrick.bren...@zaisgroup.com wrote:
 We installed Subversion on a Windows 2003 Standard SP2 Server box.
 Installed from exe file downloaded from website.

What website? I can think of at least 3 distributions of Subversion
built for Windows  packaged into an installer.

 Chose windows authentication and created top level repository.
 We know nothing about this software as it was just dumped in our laps so 
 sorry about the lack of useful information.


You might want to talk to the people who dumped it in your laps too.


 -Original Message-
 From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
 Sent: Monday, November 29, 2010 7:32 PM
 To: Patrick Brennan
 Cc: users@subversion.apache.org; Stephen Epstein
 Subject: Re: Subversion Authentication

 On Mon, Nov 29, 2010 at 2:42 PM, Patrick Brennan
 patrick.bren...@zaisgroup.com wrote:
 Hello,



 We have a default install of Subversion software and our users are
 requesting Authentication be setup for our Developers Domain group and a
 Domain group in another sister domain.

 What is a default install? A Linux box with RPM's from RPMforge, a
 Windows server with a particular toolkit, or what?

 Any Apache based server that can handle mod_auth_kerb can use the
 underlying Kerberos login names and passwords that Active Directory is
 built on. That doesn't get you group management, but it's a starting
 place. Be aware that Linux and UNIX and CygWin svn command line
 clients, by default, will store the HTTP or HTTPS passwords in clear
 text in the user's home directory: this is why I generally refuse to
 use this.

 But if you can somehow prevent such access, or have confidence in your
 users not to use such tools, it should be straightforward to set up.
 Group information and privileges, well, you'd have to give better
 ideas of what you're trying to allow, and what you're trying to
 prevent. And you *really* need to go read the Subversion book at
 http://svnbook.red-bean.com/, focusing on the access control chapters.
 Especially look here:
 http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd.authn

 We have no idea how to do this to disable everyone from having access which
 they do now and only give access to select domain groups.

 Any help would be appreciated.

 

 This e-mail message is intended only for the named recipient(s) above. It may 
 contain confidential information. If you are not the intended recipient you 
 are hereby notified that any dissemination, distribution or copying of this 
 e-mail and any attachment(s) is strictly prohibited. If you have received 
 this e-mail in error, please immediately notify the sender by replying to 
 this e-mail and delete the message and any attachment(s) from your system. 
 Thank you.

 This is not an offer (or solicitation of an offer) to buy/sell the 
 securities/instruments mentioned or an official confirmation. This is not 
 research and is not from ZAIS Group but it may refer to a research 
 analyst/research report. Unless indicated, these views are the author's and 
 may differ from those of ZAIS Group research or others in the Firm. We do not 
 represent this is accurate or complete and we may not update this. Past 
 performance is not indicative of future returns.


 IRS CIRCULAR 230 NOTICE:.


 To comply with requirements imposed by the IRS, we inform you that any U.S. 
 federal tax advice contained herein (including any attachments), unless 
 specifically stated otherwise, is not intended or written to be used, and 
 cannot be used, for the purpose of (i) avoiding penalties under the Internal 
 Revenue Code or (ii) promoting, marketing or recommending any transaction or 
 matter addressed herein to another party.  Each taxpayer should seek advice 
 based on the taxpayer's particular circumstances from an independent tax 
 advisor.

 ZAIS, ZAIS Group and ZAIS Solutions are trademarks of ZAIS Group, LLC.

Re: AW: How to find out the rev number where a file was deleted?

2010-11-30 Thread Les Mikesell 

On 11/30/10 7:35 AM, Andrey Repin wrote:



Binary search on the 0 to HEAD revision range is a possibility, but it's
also a rather wasteful workaround.



Fisheye (a commercial product) does a brute-force extract/index of all
the filenames and content in all revs in a repo for quick searches.
I'm not sure if there is any equivalent open source program but this is
probably the right answer for anyone who needs to do that frequently.


Sorry, do you mean that we have to pay to cover the lack of functionality in
Subversion? And it should remain this way?


Yes, I would not expect fast indexed full-text searches across names and content 
to ever be a part of the version control system itself.  But the functionality 
to find filename changes is there - just 'log -v' from the top.



There's a big problem here - whether a URL exists or not usually isn't
the right answer for things that have been deleted and replaced by
something else of the same name.


I strongly suspect that Ludwig had in mind that Subversion could track
revisions in which file has been changed in either way.
Then no way you could confuse between different files with same URL.


It does track that, but I don't think there is a convenient way to ask for it. 
Or for the server itself to find it efficiently.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Subversion Authentication

2010-11-30 Thread Andy Levy 
On Tue, Nov 30, 2010 at 09:10, Patrick Brennan
patrick.bren...@zaisgroup.com wrote:
 This is from the readme file

 VisualSVN Server 2.1.4
 --

 VisualSVN Server is a package that contains everything you need to install,
 configure and manage Subversion server for your team on Windows platform. It
 includes Subversion, Apache and a management console.

 This distribution contains the following components:
 - Subversion 1.6.13
 - Apache 2.2.13
 - OpenSSL 0.9.8l
 - ZLib 1.2.3
 - Neon 0.29.3

 For more information please visit http://www.visualsvn.com/server/


Then you should be able to manage everything via the MMC snap-in if
your domains are set up witht he right relationship.

But that might also be more complex than that application can handle.
Ask the VisualSVN Server people about it.

And PLEASE stop top-posting.


 -Original Message-
 From: Andy Levy [mailto:andy.l...@gmail.com]
 Sent: Tuesday, November 30, 2010 8:48 AM
 To: Patrick Brennan
 Cc: users@subversion.apache.org
 Subject: Re: Subversion Authentication

 On Tue, Nov 30, 2010 at 08:43, Patrick Brennan
 patrick.bren...@zaisgroup.com wrote:
 We installed Subversion on a Windows 2003 Standard SP2 Server box.
 Installed from exe file downloaded from website.

 What website? I can think of at least 3 distributions of Subversion
 built for Windows  packaged into an installer.

 Chose windows authentication and created top level repository.
 We know nothing about this software as it was just dumped in our laps so 
 sorry about the lack of useful information.


 You might want to talk to the people who dumped it in your laps too.


 -Original Message-
 From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
 Sent: Monday, November 29, 2010 7:32 PM
 To: Patrick Brennan
 Cc: users@subversion.apache.org; Stephen Epstein
 Subject: Re: Subversion Authentication

 On Mon, Nov 29, 2010 at 2:42 PM, Patrick Brennan
 patrick.bren...@zaisgroup.com wrote:
 Hello,



 We have a default install of Subversion software and our users are
 requesting Authentication be setup for our Developers Domain group and a
 Domain group in another sister domain.

 What is a default install? A Linux box with RPM's from RPMforge, a
 Windows server with a particular toolkit, or what?

 Any Apache based server that can handle mod_auth_kerb can use the
 underlying Kerberos login names and passwords that Active Directory is
 built on. That doesn't get you group management, but it's a starting
 place. Be aware that Linux and UNIX and CygWin svn command line
 clients, by default, will store the HTTP or HTTPS passwords in clear
 text in the user's home directory: this is why I generally refuse to
 use this.

 But if you can somehow prevent such access, or have confidence in your
 users not to use such tools, it should be straightforward to set up.
 Group information and privileges, well, you'd have to give better
 ideas of what you're trying to allow, and what you're trying to
 prevent. And you *really* need to go read the Subversion book at
 http://svnbook.red-bean.com/, focusing on the access control chapters.
 Especially look here:
 http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd.authn

 We have no idea how to do this to disable everyone from having access which
 they do now and only give access to select domain groups.

 Any help would be appreciated.

 

 This e-mail message is intended only for the named recipient(s) above. It 
 may contain confidential information. If you are not the intended recipient 
 you are hereby notified that any dissemination, distribution or copying of 
 this e-mail and any attachment(s) is strictly prohibited. If you have 
 received this e-mail in error, please immediately notify the sender by 
 replying to this e-mail and delete the message and any attachment(s) from 
 your system. Thank you.

 This is not an offer (or solicitation of an offer) to buy/sell the 
 securities/instruments mentioned or an official confirmation. This is not 
 research and is not from ZAIS Group but it may refer to a research 
 analyst/research report. Unless indicated, these views are the author's and 
 may differ from those of ZAIS Group research or others in the Firm. We do 
 not represent this is accurate or complete and we may not update this. Past 
 performance is not indicative of future returns.


 IRS CIRCULAR 230 NOTICE:.


 To comply with requirements imposed by the IRS, we inform you that any U.S. 
 federal tax advice contained herein (including any attachments), unless 
 specifically stated otherwise, is not intended or written to be used, and 
 cannot be used, for the purpose of (i) avoiding penalties under the Internal 
 Revenue Code or (ii) promoting, marketing or recommending any transaction or 
 matter addressed herein to another party.  Each taxpayer should seek advice 
 based on the taxpayer's particular circumstances from an independent tax

Re: How to find out the rev number where a file was deleted?

2010-11-30 Thread Les Mikesell 

On 11/30/2010 7:39 AM, Andrey Repin wrote:

Greetings, Les Mikesell!


Still, this should at least produce some results:  (as long as foo existed
in rev 3)
   svn log -r 0:head file://${HOME}/trash/repo/f...@3
   svn: File not found: revision 5, path '/foo'
It makes no sense for svn to complain about what's in rev 5.  My query
doesn't care about rev 5.



I think the principle was covered in another response, but the only way
you can get history is to start from the highest rev and follow
backwards, and you are asking it to start from head, which is impossible.


Impossible within current realization of storage backend. But sensible from
user's viewpoint and scheduled to be resolved in future.
I'd ask you to stop giving out your own opinion under mask of absolute truth.


I'm admittedly not an expert, but I don't understand exactly how this 
can be resolved to work the way you want when the names of objects are 
only loosely connected to the objects themselves.  That is, a path and 
revision in peg revision form uniquely identifies an object, and that 
object has a certain amount of history.  However that same path at any 
other revision may be an entirely different object with a different 
history or may not exist at all.  If subversion starts to track the 
'copy-to' info so you can follow revisions in the forward direction, you 
can end up with many different descendants with different paths, but 
it's not clear that would make it any easier to find the dead ends of 
deletions.


I can see that subversion could, with some extra work on the server 
side, track down the end of the line in the future of f...@3 by examining 
every subsequent revision when you ask for:

svn log -r 0:head file://${HOME}/trash/repo/f...@3
But what should it do if a different object with the same name but a 
different history has been copied into head where you are really asking 
it to start giving history?


Also, when you copy a directory in subversion, you expect it to bring 
along all of the history of that directory and the objects under it.  If 
you want it to remember that a deleted object once lived under a certain 
path, when that path is copied, would you also want it to think that the 
deleted object was once under this new copied path?


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Status of SVNPathAuthz short_circuit

2010-11-30 Thread JamieEchlin 



Bruno De Fraine wrote:
 
 Is my interpretation of short_circuit v.s. regular path-based
 authorization correct? Or if not, what is the impact of short_circuit?
 Since performance problems are so apparent with path-based authorization,
 why is this seemingly useful option given so little attention?
 

This is an excellent question, I have the same issues as Bruno, and I really
can't add anything to the question to make it clearer. Just that, to
rephrase, under what circumstances should you not use short_circuit?

NB Unfortunately the replies to this thread should actually be a different
thread.

cheers, jamie
-- 
View this message in context: 
http://old.nabble.com/Status-of-SVNPathAuthz-short_circuit-tp29354617p30341951.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: AW: How to find out the rev number where a file was deleted?

2010-11-30 Thread Andrey Repin 
Greetings, Les Mikesell!

 Binary search on the 0 to HEAD revision range is a possibility, but it's
 also a rather wasteful workaround.

 Fisheye (a commercial product) does a brute-force extract/index of all
 the filenames and content in all revs in a repo for quick searches.
 I'm not sure if there is any equivalent open source program but this is
 probably the right answer for anyone who needs to do that frequently.

 Sorry, do you mean that we have to pay to cover the lack of functionality in
 Subversion? And it should remain this way?

 Yes, I would not expect fast indexed full-text searches across names and 
 content 
 to ever be a part of the version control system itself.  But the 
 functionality 
 to find filename changes is there - just 'log -v' from the top.

Where you see a reference to full-text search in my quote? I have intentionally
omit that part of your reply.

 There's a big problem here - whether a URL exists or not usually isn't
 the right answer for things that have been deleted and replaced by
 something else of the same name.

 I strongly suspect that Ludwig had in mind that Subversion could track
 revisions in which file has been changed in either way.
 Then no way you could confuse between different files with same URL.

 It does track that, but I don't think there is a convenient way to ask for 
 it. 
 Or for the server itself to find it efficiently.

It only track it back into the past.
There's no sane way to track it forward currently.
I see some complications in implementation of this ability, mainly in the
controversial way it should work (i.e. alter multiple previous revisions to
embed the forward tracking links, or to maintain a parallel base for them).


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 30.11.2010, 21:10

Sorry for my terrible english...

Re: AW: How to find out the rev number where a file was deleted?

2010-11-30 Thread Les Mikesell 

On 11/30/2010 12:04 PM, Ludwig, Michael wrote:




But the name has nothing to do with the versioning of the
object.


True, but many humans tend to attach meaning to names, to remember
them, and to refer to them. For example, names often appear in the
contents of other files. They just have a tendency of cropping up
here and there. People might find it useful if Subversion had
better support for this.


But when humans use names they have to understand their non-unique 
nature or face surprises.  If there was a Les Mikesell before 1949, it 
wasn't me.  If there are others now, they aren't me either. Subversion 
represents a matrix of paths and time; different names come and go over 
time and very often many different names refer to the same thing and the 
same name may to different things at different times.




Where does the client/server protocol have such functionality
now?  I think it is only in showing a log -v of the directory
containing the name.


It doesn't have this functionality right now. You'd have to parse
the output of log -v, yes. It's onerous on both the server and
the human.


Saying you don't like to parse the answer isn't the same as saying it 
doesn't have the functionality.



That already exists.  A 'log -v' from the top of the repo will
show all deletes and adds ever done.  The output isn't
convenient to feed to grep, etc., though.


It would work, somehow. I'm aware of that. I'm just imagining a
more convenient feature that also performs better. A lookup
instead of a scan.


There are lots of other places I would consider more important than 
making it easy to find something you deleted on purpose.  A handy way to 
track where something went when you later copied to a tag might be 
something people would be more likely to want to know frequently - but 
again, the answer might be large and hard to parse because there's no 
particular limit to the number of copies that could have been made.  And 
if you did have the name lookup you want, you still have to deal with 
the issue that in every rev where the name is found it may be some 
different object.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: How to find out the rev number where a file was deleted?

2010-11-30 Thread Andrey Repin 
Greetings, Les Mikesell!

 Still, this should at least produce some results:  (as long as foo existed
 in rev 3)
svn log -r 0:head file://${HOME}/trash/repo/f...@3
svn: File not found: revision 5, path '/foo'
 It makes no sense for svn to complain about what's in rev 5.  My query
 doesn't care about rev 5.

 I think the principle was covered in another response, but the only way
 you can get history is to start from the highest rev and follow
 backwards, and you are asking it to start from head, which is impossible.

 Impossible within current realization of storage backend. But sensible from
 user's viewpoint and scheduled to be resolved in future.
 I'd ask you to stop giving out your own opinion under mask of absolute truth.

 I'm admittedly not an expert, but I don't understand exactly how this 
 can be resolved to work the way you want when the names of objects are 
 only loosely connected to the objects themselves.

This is not a problem at all.
The simplest solution I can imagine is to maintain a table
revision|URL|action|previous_revision|previous_URL

Walking this table back and forth is as quick as any usual database operation.
And some new command could be added to svn program to give result similar to
status command, but including revision numbers.
Something like
A  5 /trunk/frontend/fig1.php
MM 7 /trunk/frontend/fig1.php
M  8 /trunk/frontend/fig1.php
D  26 /trunk/frontend/fig1.php
A  57 /trunk/frontend/f-o.php
R  58 /trunk/frontend/fig1.php
C  59 /branch/xxx/frontend/fig1.php
GM 77 /trunk/frontend/fig1.php

(Yes, there's a reference to the moment file has been Copied, but that's only
made for reference, to give investigator an idea of what could've been done to
the file, and where to look. As you can see, the file was merGed back to the
trunk in my example, but no mention if it was edited in between 59 and 77 -
you'd have to run another track for that file in branch to discover that)

 That is, a path and revision in peg revision form uniquely identifies an
 object, and that object has a certain amount of history.
 However that same path at any other revision may be an entirely different
 object with a different history or may not exist at all.  If subversion
 starts to track the 'copy-to' info so you can follow revisions in the
 forward direction, you can end up with many different descendants with
 different paths, but it's not clear that would make it any easier to find
 the dead ends of deletions.

If it start to branch, each of these files will have it's own tracking onward
from the branching point. Nothing wrong with it. Or do you concerned with
tracking request output? It's not a problem either. As long as URL wasn't
renamed/deleted, it should keep giving out the mainline.

You're right that u...@peg form an unique identity, but making a mistake
thinking about URL across whole range of history. As you pointed out, URL
alone isn't enough to identify the file. But that's not a problem, because
Subversion wouldn't be working over whole repository, only with each revision
it know of, sequentially.

 I can see that subversion could, with some extra work on the server 
 side, track down the end of the line in the future of f...@3 by examining 
 every subsequent revision when you ask for:
 svn log -r 0:head file://${HOME}/trash/repo/f...@3
 But what should it do if a different object with the same name but a 
 different history has been copied into head where you are really asking 
 it to start giving history?

If it'd be implemented right, Subversion would not see these files at all.
It'd simply NOT look into HEAD in first place.

 Also, when you copy a directory in subversion, you expect it to bring 
 along all of the history of that directory and the objects under it.  If 
 you want it to remember that a deleted object once lived under a certain 
 path, when that path is copied, would you also want it to think that the 
 deleted object was once under this new copied path?

You asking a question that has no meaning. Subversion copy copies current
state. Deleted files do not present in it.
I don't see any problem. Or clarify your question. (provide use-case?)


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 30.11.2010, 21:22

Sorry for my terrible english...

Re: AW: How to find out the rev number where a file was deleted?

2010-11-30 Thread Les Mikesell 

On 11/30/2010 12:19 PM, Andrey Repin wrote:



Yes, I would not expect fast indexed full-text searches across names and content
to ever be a part of the version control system itself.  But the functionality
to find filename changes is there - just 'log -v' from the top.


Where you see a reference to full-text search in my quote? I have intentionally
omit that part of your reply.


I think you are asking for a search for the text of a path/filename 
across revisions - but maybe that was the way someone else interpreted 
the problem.  Following an object's path as it may fan out into 
different paths/names or be deleted in later revs is a somewhat 
different concept and perhaps closer to what you need to convert your

svn log -r 0:head file://${HOME}/trash/repo/f...@3
transparently into
svn log -r 0:4 file://${HOME}/trash/repo/f...@3
But, if you had tagged this version or made similar copies elsewhere or 
renamed it, wouldn't you want a forward-following system to track into 
the new path(s) as it does going backwards now instead of ending when 
one of its names was deleted?


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Db based configuration for per-directory access control

2010-11-30 Thread David Weintraub 
2010/11/25 Hoping White baihaop...@gmail.com:
 Hi all

 Is there any way to configure subversion to do per-directory access
 control via database not config file? I have googled a lot, and all
 found are telling how to configure apache login problem, not svn
 repository access control.


The access control file is simply a text file. It should be fairly
simple to read from a database, and create the text file from the
database. In fact, most database programs have triggers that can
trigger a program to execute whenever a database change is detected.

My experience has been that when the text file gets changed under
svnserve, the access is also changed without a restart of the
svnserve. This is a bit different from http/apache which requires a
restart of the httpd daemon.

Yes, this isn't a direct database control situation, but it will do
what you want: A change in the access control database changes the
access control in Subversion.

And, it really shouldn't be that difficult to do.

-- 
David Weintraub
qazw...@gmail.com

subversion cross compile (arm)

2010-11-30 Thread Takács András 
Hi All,

I have problem with cross-compiling of subversion for arm. I'm using
codesourcery toolchain. (See build details below).

My test method (after flashing my developement board):
# svnadmin create /var/svn/testrepo
# svnserve --config-file /etc/svnserve.cfg -d -r /var/svn
# svn co svn://wako...@127.0.0.1/testrepo
# cd testrepo/
# svn mkdir xxx
# svn ci -m aa
Authentication realm: svn://127.0.0.1:3690
1bef6e06-1dd2-11b2-866e-650b8393a604
Password for 'root':
Authentication realm: svn://127.0.0.1:3690
1bef6e06-1dd2-11b2-866e-650b8393a604
Username: wakoond
Password for 'wakoond':

---
ATTENTION!  Your password for authentication realm:

   svn://127.0.0.1:3690 1bef6e06-1dd2-11b2-866e-650b8393a604

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/.subversion/servers'.
---
Store password unencrypted (yes/no)? yes
Adding xxx
svn: Commit failed (details follow):
svn: Corrupt node-revision '0.0.t0-0'
svn: Malformed text representation offset line in node-rev


Could you please help me? What's the problem? Is it a build/configure
or a toolchain/libc problem?
Did anybody cross-compiled subversion for arm4t platform previously?

Thanks a lot! Really, I'm very thankful for everything!

Regards,
András



Toolchain: arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu
Cross gcc:  arm-none-linux-gnueabi-gcc
Cross cflags: -march=armv4t -mtune=arm920t

Apr configure:
./configure \
--prefix=/usr \
--host=$(CROSS_COMPILE) \
ac_cv_file__dev_zero=yes \
ac_cv_func_setpgrp_void=yes \
apr_cv_process_shared_works=yes \
apr_cv_mutex_robust_shared=no \
apr_cv_tcp_nodelay_with_cork=yes \
ac_cv_sizeof_struct_iovec=8 \
apr_cv_mutex_recursive=yes \
CFLAGS=$(CROSS_CFLAGS) \
LDFLAGS=$(CROSS_LDFLAGS)

Apr-utils configure:
./configure \
--with-apr=MY_APR_BUILD_DIR \
--prefix=/usr \
--host=$(CROSS_COMPILE) \
CFLAGS=$(CROSS_CFLAGS) \
LDFLAGS=$(CROSS_LDFLAGS); \

Subversion configure:
./configure \
--with-apr=$(PACKAGES_DIR)/apr/$(TARGET_PACKAGE)/apr \

--with-apr-util=$(PACKAGES_DIR)/apr-util/$(TARGET_PACKAGE)/apr-util \
--with-sqlite=$(TARGET_DEV_ROOT)/usr \
--with-zlib=$(TARGET_DEV_ROOT)/usr \
--host=$(CROSS_COMPILE) \
--prefix=/usr \
CFLAGS=$(CROSS_CFLAGS) \
LDFLAGS=$(CROSS_LDFLAGS)

Other compiled libraries: sqlite3, zlib
I'm usung the latest, 1.6.15 subversion and subversion-deps packages.
(I compiled all libraries from subversion-deps, no other installed library)

--
Takács András
Skype: wakoond
GTalk: wakoond
MSN: wako...@freestart.hu

Re: prevent Linux root from seeing my files

2010-11-30 Thread Chris Albertson 
I think the bottom line here is that your only for sure method is to
do all the encryption and decryption
on your own local computer.  But as others have said this means
SVN sees only binary blobs.

You can not depend on the server unless you completely trust
Root.  But if you trust him why not simply tell him not to look?
With an untrustful Root you can not depend on an encrypted
file system on the sever.   It would be easy
for Root to pach it such that no encryption takes place and you'd
never know it was patched.


I work with data that can't be shared.   As it turns out most of
the compromises that occur are human error or procedural
problems.  and no, you can't depend on people promising to
not make mistakes.  You have to organized your work and
systems so that they are fail safe.   One hard and fast rule is
to NEVER connect a computer that holds sensitive information
to the Internet.  Move the data through an air gap.

You have to decide if your data is really that sensitive


-- 
=
Chris Albertson
Redondo Beach, California

Re: Db based configuration for per-directory access control

2010-11-30 Thread Andy Levy 
On Tue, Nov 30, 2010 at 14:39, David Weintraub qazw...@gmail.com wrote:
 2010/11/25 Hoping White baihaop...@gmail.com:
 Hi all

 Is there any way to configure subversion to do per-directory access
 control via database not config file? I have googled a lot, and all
 found are telling how to configure apache login problem, not svn
 repository access control.


 The access control file is simply a text file. It should be fairly
 simple to read from a database, and create the text file from the
 database. In fact, most database programs have triggers that can
 trigger a program to execute whenever a database change is detected.

 My experience has been that when the text file gets changed under
 svnserve, the access is also changed without a restart of the
 svnserve. This is a bit different from http/apache which requires a
 restart of the httpd daemon.

We update our SVN authz  access files a few times a week and never
have to restart Apache.

Re: How to find out the rev number where a file was deleted?

2010-11-30 Thread Les Mikesell 

On 11/30/2010 12:58 PM, Andrey Repin wrote:

Greetings, Les Mikesell!


Still, this should at least produce some results:  (as long as foo existed
in rev 3)
svn log -r 0:head file://${HOME}/trash/repo/f...@3
svn: File not found: revision 5, path '/foo'
It makes no sense for svn to complain about what's in rev 5.  My query
doesn't care about rev 5.



I think the principle was covered in another response, but the only way
you can get history is to start from the highest rev and follow
backwards, and you are asking it to start from head, which is impossible.


Impossible within current realization of storage backend. But sensible from
user's viewpoint and scheduled to be resolved in future.
I'd ask you to stop giving out your own opinion under mask of absolute truth.



I'm admittedly not an expert, but I don't understand exactly how this
can be resolved to work the way you want when the names of objects are
only loosely connected to the objects themselves.


This is not a problem at all.
The simplest solution I can imagine is to maintain a table
revision|URL|action|previous_revision|previous_URL

Walking this table back and forth is as quick as any usual database operation.


What database operation is fast when it has to follow recursive 
self-references in the same table?  Each time you copy a high level 
directory (typical for users that tag frequently) you'd have to have an 
entry for every path below it.  When you follow forward, you'll explode 
out a tree of new paths.



And some new command could be added to svn program to give result similar to
status command, but including revision numbers.
Something like
A  5 /trunk/frontend/fig1.php
MM 7 /trunk/frontend/fig1.php
M  8 /trunk/frontend/fig1.php
D  26 /trunk/frontend/fig1.php
A  57 /trunk/frontend/f-o.php
R  58 /trunk/frontend/fig1.php
C  59 /branch/xxx/frontend/fig1.php
GM 77 /trunk/frontend/fig1.php


And how should this look if every operation is a move/rename? Or copies 
followed by different renames out each branch?



If it start to branch, each of these files will have it's own tracking onward
from the branching point. Nothing wrong with it. Or do you concerned with
tracking request output? It's not a problem either. As long as URL wasn't
renamed/deleted, it should keep giving out the mainline.


But that's the point.  Things are copied and moved regularly.  And 
renamed temporarily and then back.



You're right that u...@peg form an unique identity, but making a mistake
thinking about URL across whole range of history. As you pointed out, URL
alone isn't enough to identify the file. But that's not a problem, because
Subversion wouldn't be working over whole repository, only with each revision
it know of, sequentially.


There's only one way back through history but no limit to future 
branches if you want it to look forward.



I can see that subversion could, with some extra work on the server
side, track down the end of the line in the future of f...@3 by examining
every subsequent revision when you ask for:
svn log -r 0:head file://${HOME}/trash/repo/f...@3
But what should it do if a different object with the same name but a
different history has been copied into head where you are really asking
it to start giving history?


If it'd be implemented right, Subversion would not see these files at all.
It'd simply NOT look into HEAD in first place.


It only looks in head because that command asks it for the history of 
head.  If you are asking it to follow the object forward for as long as 
it existed in that path the server could probably figure that out with 
some brute force although even there things would be messy if you 
renamed it, then renamed it back some revisions later.  Or maybe made 
many copies, one of which was eventually copied back.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

2010-11-30 Thread Daniel Shahaf 
Danny Trebbien wrote on Tue, Nov 30, 2010 at 07:35:38 -0800:
 I suspect that when all is said and done, the version of Subversion
 that will contain the patch will be in the 1.7.x series.

Indeed.  We don't add new features in patch releases (1.6.0-1.6.x), and
I'm afraid that Danny's patches do qualify as new features in this
context...

(They add new API's and new --flags.)

Daniel

Re: subversion cross compile (arm)

2010-11-30 Thread Daniel Shahaf 
Takács András wrote on Tue, Nov 30, 2010 at 20:36:55 +0100:
 Hi All,
 
 I have problem with cross-compiling of subversion for arm. I'm using
 codesourcery toolchain. (See build details below).
 
 My test method (after flashing my developement board):
 # svnadmin create /var/svn/testrepo
 # svnserve --config-file /etc/svnserve.cfg -d -r /var/svn
 # svn co svn://wako...@127.0.0.1/testrepo
 # cd testrepo/
 # svn mkdir xxx
 # svn ci -m aa
 Adding xxx
 svn: Commit failed (details follow):
 svn: Corrupt node-revision '0.0.t0-0'
 svn: Malformed text representation offset line in node-rev
 

I'd use file:/// for testing.

I suppose the next hint (unless someone has tips specific to arm) would
be to see the corrupt lines in the revision file --- can you share them?
You can patch or breakpoint in subversion/libsvn_fs_fs/fs_fs.c (that is
where the error is generated) to find what lines it complains about.

You can pass --enable-maintainer-mode to configure to get some debug
aids: asserts, debug symbols, stack traces in the error message.

 
 Could you please help me? What's the problem? Is it a build/configure
 or a toolchain/libc problem?
 Did anybody cross-compiled subversion for arm4t platform previously?
 
 Thanks a lot! Really, I'm very thankful for everything!
 
 Regards,
 András
 
 
 
 Toolchain: arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu
 Cross gcc:  arm-none-linux-gnueabi-gcc
 Cross cflags: -march=armv4t -mtune=arm920t
 
 Apr configure:
   ./configure \
   --prefix=/usr \
   --host=$(CROSS_COMPILE) \
   ac_cv_file__dev_zero=yes \
   ac_cv_func_setpgrp_void=yes \
   apr_cv_process_shared_works=yes \
   apr_cv_mutex_robust_shared=no \
   apr_cv_tcp_nodelay_with_cork=yes \
   ac_cv_sizeof_struct_iovec=8 \
   apr_cv_mutex_recursive=yes \
   CFLAGS=$(CROSS_CFLAGS) \
   LDFLAGS=$(CROSS_LDFLAGS)
 
 Apr-utils configure:
   ./configure \
   --with-apr=MY_APR_BUILD_DIR \
   --prefix=/usr \
   --host=$(CROSS_COMPILE) \
   CFLAGS=$(CROSS_CFLAGS) \
   LDFLAGS=$(CROSS_LDFLAGS); \
 
 Subversion configure:
   ./configure \
   --with-apr=$(PACKAGES_DIR)/apr/$(TARGET_PACKAGE)/apr \
   
 --with-apr-util=$(PACKAGES_DIR)/apr-util/$(TARGET_PACKAGE)/apr-util \
   --with-sqlite=$(TARGET_DEV_ROOT)/usr \
   --with-zlib=$(TARGET_DEV_ROOT)/usr \
   --host=$(CROSS_COMPILE) \
   --prefix=/usr \
   CFLAGS=$(CROSS_CFLAGS) \
   LDFLAGS=$(CROSS_LDFLAGS)
 
 Other compiled libraries: sqlite3, zlib
 I'm usung the latest, 1.6.15 subversion and subversion-deps packages.
 (I compiled all libraries from subversion-deps, no other installed library)
 
 --
 Takács András
 Skype: wakoond
 GTalk: wakoond
 MSN: wako...@freestart.hu

Re: subversion cross compile (arm)

2010-11-30 Thread Takács András 
Hi!

 I'd use file:/// for testing.

Same result :(

 I suppose the next hint (unless someone has tips specific to arm) would
 be to see the corrupt lines in the revision file --- can you share them?
 You can patch or breakpoint in subversion/libsvn_fs_fs/fs_fs.c (that is
 where the error is generated) to find what lines it complains about.
 You can pass --enable-maintainer-mode to configure to get some debug
 aids: asserts, debug symbols, stack traces in the error message.

The problem is at this line in fs_fs.c:
if ((str == NULL) || (strlen(str) != (APR_MD5_DIGESTSIZE * 2)))
Here the length of str is 6, and APR_MD5_DIGESTSIZE*2 should be 32.

Sorry, but I don't know which is the revision file, I'm not too
familiar with svn internals. (I'm just using it)
Did you mean the entries file from the .svn directory? I pasted it below.

Thanks!

Regards,
András



# cat .svn/entries
10

dir
0
file:///var/svn/testrepo
file:///var/svn/testrepo



1970-01-01T00:00:14.631784Z
0















1c376b8e-1dd2-11b2-8415-0399146d2571


xxx
dir



add


/home/testrepo #

RE: Status of SVNPathAuthz short_circuit

2010-11-30 Thread Cooke, Mark 
 Bruno De Fraine wrote:
  
  Is my interpretation of short_circuit v.s. regular path-based
  authorization correct? Or if not, what is the impact of 
 short_circuit?
  Since performance problems are so apparent with path-based 
 authorization,
  why is this seemingly useful option given so little attention?
  
 
 -Original Message-
 From: JamieEchlin [mailto:jamie.ech...@credit-suisse.com] 
 Sent: 30 November 2010 17:55
 To: users@subversion.apache.org
 Subject: Re: Status of SVNPathAuthz short_circuit
 
 This is an excellent question, I have the same issues as 
 Bruno, and I really
 can't add anything to the question to make it clearer. Just that, to
 rephrase, under what circumstances should you not use short_circuit?
 
 NB Unfortunately the replies to this thread should actually 
 be a different
 thread.
 
 cheers, jamie
 -- 
 View this message in context: 

http://old.nabble.com/Status-of-SVNPathAuthz-short_circuit-tp29354617p30
341951.html
 Sent from the Subversion Users mailing list archive at Nabble.com.
 
Hmm, interesting, I had not really looked at that part of my
configuration.

My reading is, like yours, that 'short-circuit' ignores any other
authorisation mechanism that may be configured in apache by talking
directly to mod_authz_svn...  So if you ever tried to configure a
different directory-access-control module, it would be _silently_
ignored.  The risk is someone trying to change the authz provider (or
add a new one) and wondering why it isn't working!

I think I will try `short-circuit` for myself and see if it helps us
too.  Thanks for highlighting it.

~ mark c

Re: subversion cross compile (arm)

2010-11-30 Thread Daniel Shahaf 
Takács András wrote on Wed, Dec 01, 2010 at 08:16:56 +0100:
  I suppose the next hint (unless someone has tips specific to arm) would
  be to see the corrupt lines in the revision file --- can you share them?
  You can patch or breakpoint in subversion/libsvn_fs_fs/fs_fs.c (that is
  where the error is generated) to find what lines it complains about.
 
 The problem is at this line in fs_fs.c:
 if ((str == NULL) || (strlen(str) != (APR_MD5_DIGESTSIZE * 2)))
 Here the length of str is 6, and APR_MD5_DIGESTSIZE*2 should be 32.
 
 Sorry, but I don't know which is the revision file, I'm not too
 familiar with svn internals. (I'm just using it)
 Did you mean the entries file from the .svn directory? I pasted it below.
 

No; the error is in the libsvn_fs libraries, which is roughly the
opposite end of the world relative to libsvn_wc's entries files...
(and I bet the error will reproduce even with 'svn mkdir URL', which
doesn't involve an entries file at all)

When the error occurs, fs_fs.c is reading a node-revision header from
some file; and that header is corrupt.  I asked you to look in *that*
file (it will be somewhere under /var/run/svn/db/) and see in what way
it is corrupted.  For example, what is the value of read_rep_offsets()'s
second parameter?

For reference, read_rep_offsets() --- the function where that error
occurs --- is the function that parses the text: line in the
following:

[[[
id: c-1.0.r1/998
type: file
count: 0
text: 1 106 44 32 8ac35a19435b31b928de300b32e930cd 
b3f85be4422626e7443b6ddcf60bb451dc7f0560 0-0/_e
cpath: /trunk/A/B/E/alpha
copyroot: 0 /
]]]

so the second parameter is expected to contain the 1 106 ... 0-0/_e string.

 Thanks!
 
 Regards,
 András