Re: something about permission

[LiuYan 刘研]

肖晗  gmail.com> writes:

> 
> 
> I set up a svn server on my own Ubuntu\Linux.
> When I enter commands like "svn commit filename", the terminal will remind me 
that I have no permission to do that.(Of course, except for the case when I 
add "sudo" to the head)
> Then I wonder, if clients from different PCs try to commit something, how do 
they get such permission?
> 
> Thanks in advance!
> 
I'm new to subversion too, but I think your permission issue should related to 
what kind server you've setup. i.e. is your svn server URL like file:// or 
svn:// or http:// or svn+ssh://.

There's a whole chapter to introduce the svn server configuration here:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.html

Wish it can help you.

Re: svn Farm

[Stephen Connolly]

On 17 October 2010 08:52, Alan Barrett  wrote:
> On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
>> > What he really wants is an alternate-universe Subversion which never
>> > had the plaintext password storage feature in the first place.
>>
>> I'd settle for being able to block that local use on the server side:
>
> OK, so you want a feature in which the client reports to the server
> "here are some important aspects of my configuration", and the server
> replies "I don't like  aspect of your configuration, so I refuse
> to work with you".  I suggest that you write up a proposal for such a
> feature, or begin a focused discussion about how such a feature could
> work and could be useful.
>
> --apb (Alan Barrett)
>

The reality is if you don't trust the client, then you don't trust the
client so how can you trust it to report what it supports correctly?

It would be trivial to fork svn to lie and report that it only stored
passwords encrypted, stick that forked client on my machine and hey
presto, away I go storing my password in plaintext.

I think that the best compromise would be for the SVN client to report
its capabilities like the SVN 1.5+ clients do:

You can have a start-commit hook.  It can reject commits from clients
that don't have the "mergeinfo" capability.

http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html

And that sorts out Nico's requirement for blocking the insecure 1.4
clienst in Redhat EL/CentOS

Add a capability called "keyringenabled" to Subversion and now Nico
will probably be much happier... but of course he doesn't trust his
users so he cannot trust that they report "keyringenabled"
correctly... but he might be pragmatic enough to accept that as a
compromise.

and that's probably a feature we could add in 1.6.14 with only minor
effort (most of the work being deciding what the feature name should
be ;-) )

-Stephen

svn: Repository moved permanently to '/viewvc/incubator/thrift/trunk/lib/java/'; please relocate

[周晓青]

Hi ,
 When I checkout one svn repository,the svn return this error 
message,please tell me how to deal with and can check out?  Thanks


This email (including any attachments) is confidential and may be legally 
privileged. If you received this email in error, please delete it immediately 
and do not copy it or use it for any purpose or disclose its contents to any 
other person. Thank you.

本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。

Re: svn: Repository moved permanently to '/viewvc/incubator/thrift/trunk/lib/java/'; please relocate

[Erik Andersson]

Try:
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.ref.svn.c.switch

Cheers
/ Erik

2010/10/18 周晓青 

>  Hi ,
>
>  When I checkout one svn repository,the svn return this error
> message,please tell me how to deal with and can check out?  Thanks
>
> --
> This email (including any attachments) is confidential and may be legally
> privileged. If you received this email in error, please delete it
> immediately and do not copy it or use it for any purpose or disclose its
> contents to any other person. Thank you.
>
>
> 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
>

Re: svn: Repository moved permanently to '/viewvc/incubator/thrift/trunk/lib/java/'; please relocate

[Ryan Schmidt]

On Oct 18, 2010, at 05:35, 周晓青 wrote:

> When I checkout one svn repository,the svn return this error message,please 
> tell me how to deal with and can check out?  Thanks

http://svn.apache.org/viewvc/incubator/thrift/trunk/lib/java/ is a ViewVC URL; 
it a URL that you can call up in a web browser to look at stuff inside a 
Subversion repository, but it is not the URL of the repository itself, and you 
cannot pass that URL to a Subversion client or you will get the error message 
you reported. You need to find out what the project's Subversion repository URL 
is. In this case, it happens to be 
http://svn.apache.org/repos/asf/incubator/thrift/trunk/lib/java/

Implementing lightweight client over http. Where to start?

[Andrew Roughan]

Porting the full svn client to my environment is not something I am willing
to undertake myself.
So as an alternative I wanted to implement some Quick & Dirty interface over
HTTP hopefully with a cleartext password.
Is there a document that describes the http interfaces to svn server for
each function?

Thanks,
Andrew

Re: Encrypted repo contents

[Ryan Schmidt]

On Oct 18, 2010, at 05:58, Gary wrote:

> I want to create a repo using online storage (think Wuala or something
> similar), and am pretty keen that nobody else, including the people
> running the storage service, can get at my code. Is it possible to
> ensure the repo contents are encrypted somehow? Everything I've read on
> the subject seems to allow encrypting the connection from clients to
> server, but not the repo contents as they sit on the disc.

There is nothing in Subversion to encrypt the contents of the repository.

Re: Compiling mod_dav_svn against an installed Apache2 instance ?

[Ryan Schmidt]

On Oct 17, 2010, at 11:02, Nelson Cabral wrote:

> I downloaded apache 2.2.16 sources and compiled with make, but where
> are the binaries ? I'm not familiar with linux conventions :-/ Do
> binaries have an extension ?

No, binaries on UNIX do not have any filename extensions.

Each project is free to organize its directory structure however it likes; 
there isn't any standard place within the source directory where the binaries 
are guaranteed to be. After you've built apache, the "find" command on the 
apache source directory could help you locate where they've decided to put 
their binaries. Here's what I get on my system:

$ find httpd-2.2.16 -name apxs
httpd-2.2.16/support/apxs

By the way, it turns out apxs is not a binary at all but an executable script.

Re: Encrypted repo contents

[Bogdan Cristea]

On Monday 18 October 2010 14:42:43 Ryan Schmidt wrote:
> On Oct 18, 2010, at 05:58, Gary wrote:
> > I want to create a repo using online storage (think Wuala or something
> > similar), and am pretty keen that nobody else, including the people
> > running the storage service, can get at my code. Is it possible to
> > ensure the repo contents are encrypted somehow? Everything I've read on
> > the subject seems to allow encrypting the connection from clients to
> > server, but not the repo contents as they sit on the disc.
> 
> There is nothing in Subversion to encrypt the contents of the repository.

You could try with a precommit hook

Re: Implementing lightweight client over http. Where to start?

[Ryan Schmidt]

On Oct 18, 2010, at 06:42, Andrew Roughan wrote:

> Porting the full svn client to my environment is not something I am willing 
> to undertake myself.
> So as an alternative I wanted to implement some Quick & Dirty interface over 
> HTTP hopefully with a cleartext password.
> Is there a document that describes the http interfaces to svn server for each 
> function?

Subversion uses many other libraries to get its job done, including apr and 
apr-util, expat, neon or serf, sqlite and others, and Subversion is itself 
divided into several libraries that carry out the various tasks. I think if the 
Subversion developers could have might Subversion lighter, they would have, and 
I don't think you will be able to make any such "quick and dirty" client 
without having to reimplement most of Subversion, which, as you may know, 
represents ten years worth of work.

What is this mysterious environment you have where Subversion does not already 
run?

To answer your question, the Subversion HTTP interface is WebDAV, so you can 
read up on that.

RE: Compiling mod_dav_svn against an installed Apache2 instance ?

[Loritsch, Berin]

> From: Nelson Cabral [mailto:nelson.cab...@gmail.com] 
> 
> Not installed (find & which don't return anything).
> I guess I have to install apache-devel, haven't I? Are there 
> instructions somewhere? 'apache-devel' on google returns nothing :-/

Most linux distribution packages separate the compiled binary and the
develepment package (include headers and link libraries).  If you built
the tool from scratch you would have everything at your disposal,
although the process is a little more difficult.  There's a couple
reasons for this practice:

1) A significant number of linux boxes are still servers at heart.  That
means you are deploying to them, not compiling on them.
2) In internet DMZs, boxes need to be hardened.  That means no
compilers, no compiler artifacts, as well as a number of other security
features.

By separating the packages folks who need to do compilation can, and
folks who need to harden their servers can.


Confidentiality Note: The information contained in this message, and any 
attachments, may contain proprietary and/or privileged material. It is intended 
solely for the person or entity to which it is addressed. Any review, 
retransmission, dissemination, or taking of any action in reliance upon this 
information by persons or entities other than the intended recipient is 
prohibited. If you received this in error, please contact the sender and delete 
the material from any computer.

Re: Implementing lightweight client over http. Where to start?

[Daniel Shahaf]

To build an 'svn' client that speaks only ra_svn protocol, you'll need
to port only apr and apr-util.  No sqlite, no serf, no neon, no bdb.

You'll need to hack the build scripts to support such a client build.

(Oh, and the ra_svn protocol may be easier to reimplement than the
ra_dav protocol.)

Ryan Schmidt wrote on Mon, Oct 18, 2010 at 06:56:51 -0500:
> 
> On Oct 18, 2010, at 06:42, Andrew Roughan wrote:
> 
> > Porting the full svn client to my environment is not something I am willing 
> > to undertake myself.
> > So as an alternative I wanted to implement some Quick & Dirty interface 
> > over HTTP hopefully with a cleartext password.
> > Is there a document that describes the http interfaces to svn server for 
> > each function?
> 
> Subversion uses many other libraries to get its job done, including apr and 
> apr-util, expat, neon or serf, sqlite and others, and Subversion is itself 
> divided into several libraries that carry out the various tasks. I think if 
> the Subversion developers could have might Subversion lighter, they would 
> have, and I don't think you will be able to make any such "quick and dirty" 
> client without having to reimplement most of Subversion, which, as you may 
> know, represents ten years worth of work.
> 
> What is this mysterious environment you have where Subversion does not 
> already run?
> 
> To answer your question, the Subversion HTTP interface is WebDAV, so you can 
> read up on that.
> 

RE: UTF-16 files and inconsistent line endings

[Vojáček Aleš]

Hi all,
Another problem with UTF, now it is problem when merging 2 files which are UTF8 
(BOM) The file on local HDD is still UTF8, but the file from repository is ANSI 
:-()
IdFromKodGenerator.cs.merge-left.r43343 - ANSI but in trunk (from I'm doing 
merge is UTF-8)
IdFromKodGenerator.cs.merge-right.r43356 - branch into I'm merging is UTF-8.

Can you help me with that?
A.

-Original Message-
From: Ulrich Eckhardt [mailto:eckha...@satorlaser.com]
Sent: Thursday, October 14, 2010 1:23 PM
To: users@subversion.apache.org
Subject: Re: UTF-16 files and inconsistent line endings

On Thursday 14 October 2010, David Aldrich wrote:
> I am developing with Visual C++ Express 2008 on Windows. I needed to add
> some Japanese characters to a source file, whereupon the editor stored the
> file in UTF-16LE encoding.

Subversion doesn't support UTF-16 as text file, it treats it as unknown (raw
binary) file...

> Subversion (1.6.12) now complains that the file has inconsistent EOL-style.

...and that doesn't mix well with this text-specific setting.

You could try using UTF-8 instead, though I'm not sure how to explain that to
MSVC, maybe just storing with a BOM is enough. MSVC allows saving as UTF-8
when choosing "save as" in the "save" button's drop-down list, notepad.exe
does that if you save as UTF-8, IIRC.


> Is there a workaround for this, such as setting eol-style to CRLF (i.e. not
> native)?

Simply deleting the svn:eol-style property would also silence the warning.

Uli


--
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

checksum error

[Edward Ned Harvey]

I have a master & slave server, in US and India.  They are both 1.6.12, but
the slave was 1.5.7 until a few days ago.

 

The master is at rev 5050, but the slave will only sync up to rev 5045.
Every time it tries to sync 5046, I get a checksum error in the apache
error_log.  It says some file fails md5.

 

In order to figure out where the corruption is, I tried using a svn client,
to simply checkout that file from the master, rev 5044, 5045, 5046.  Had no
problem.  Correct me if I'm wrong, but, if the corruption were on the
server, I should have gotten the error during that operation, right?  Does
the svn sync slave do md5 checksums that the svn client doesn't do?

 

If I restore the slave from backup, and re-try the sync, it consistently
fails at 5045 trying 5046, and always the same file, and always the same
mismatched checksum.

 

Since we're drawing the conclusion that the corruption is in the slave, it
must mean that a past rev of something was corrupted and undetected.  In
fact, when I upgraded from 1.5.7 to 1.6.12, I did a dump & load.  So it
seems, if I had silently corrupted on-disk, I should have discovered the
problem at that time, right?  Unless perhaps ... 1.5 didn't do checksums so
the 1.6 dump & load has nothing from the past to verify...

 

Does 1.6 do some new md5 checksumming that 1.5 didn't do?

 

Anyway, I'm transferring a new fresh copy of the repo to the slave.  I
figure this should fix it.  But I'm extremely curious how this all happened.

Re: Subversion equivalent to VSS diff for binary files

[David Weintraub]

Subversion does handle binary files without any problems. In uses the
property svn:mime-type on the file to mark it as a binary file, so it
knows not to attempt a text merge on the file.

Subversion does a good job with handling binaries. However, there is
issue that makes storing binary files in Subversion problematic.
Subversion really doesn't have an easy way to remove individual
revisions of particular files. Normally, with text files, this isn't
an issue. Text files are stored as diffs and removing a particular
revision of a text file won't save a lot of room in the repository.
Most people don't bother removing text revisions unless the text
revision contains inappropriate or proprietary information that you
don't want kept around.

However, binary files are a bit different. Changing one line in a file
and then compiling it may cause a cascade of changes, so the resulting
difference between the previous revision of the binary and current
version of the binary are quite huge. Storing a binary file as
revisions in ANY revision control system takes up a great deal of
space when compared with storing revisions of text.

In many sites, the built objects are stored under revision control,
maybe for every single build. You do this after a while, and you'll
chew up a lot of disk space. To handle this, many sites have a way of
identifying obsolete binary revisions and destroying them. I remember
several papers in Perforce conferences on this very topic. (The idea
was to remove the space hogging binary revision without destroying the
revision itself. That way, you'd still see the history, but not have
access to the file contents).

So, the best thing to do is not to store binary files when you don't
have to. Storing binaries is done for several reasons some are:

1. Not being sure that you can repeat your build process, so you want
to keep the binary revision "just in case". The solution to this is to
create a repeatable build process, so you don't have to store the
binaries.

2. Storing releases. A very common tactic, but revision control
systems aren't really ideal for this anyway. Most people who need to
grab the releases aren't necessarily developers, so using a revision
control system to get the release they want simply adds complexity. A
better way is to use a release repository system.

3. Storing third party artifacts. This is usually not a space issue
since it is unlikely you'll be storing a hundred revisions of a
particular third party binary. You might, maybe update a third party
binary one or twice a year. The problem with this (which is a problem
with every revision control system out there) is that you quickly lose
the true identify of the third party revision. This happens all the
time with Jar files. Is that log4j.jar revision 1.2.3 or 1.4.6? How do
I know? In the end, you'll end up with a pile of unidentifiable and
probably obsolete third party binaries.

Considering that the whole purpose of revision control is identifying
what is in your software, having a wad of unknown third party binaries
isn't a great way to accomplish this task.

The true solution to this is to use a release repository system. If
you use Ant, it's quite simple to incorporate ivy, and once done, the
developers are usually quite happy with the results. Even if you
aren't working on a Java project, you should use some sort of release
repository for this type of stuff.

Should you ever store binary files in Subversion? Of course, but only
when it is really the best way to handle the problem. If your source
code includes JPGs and GIFs, or you include a Word document in your
release, there isn't really an alternative, but to store the binary
file. Space isn't an issue since these files are relatively small and
aren't updated that frequently. (Compare a few megabytes of a Word
document that you update once per month vs. storing a 1.5 gigabyte
build that you produce two to three times per day).

So, there are two sides to binaries in Subversion story:

Yes, Subversion handles binaries just as well as other revision
systems. Some say even better. Subversion knows what files are binary
by using the svn:mime-type property. In fact, Subversion can, unlike
many version control systems, actually distinguish between binary
types, and it is possible via third party tools to actually diff
binary files (like between two Word documents).

No, Subversion doesn't allow easy pruning of space hogging binaries,
and therefore it can cause problems in that respect. If you're using a
revision control system, and now have a policy of removing obsolete
binaries on a regular basis, you'll have problems continuing this with
Subversion. However, if this is a problem, it's more likely due to
incorrectly using your revision control system (unable to rebuild
order binaries in a consistent manor, or using your version control
system as a release repository). The solution would be to fix the
underlying problem rather than not to use Subversion.

-- 
David W

Re: Implementing lightweight client over http. Where to start?

[Stephen Connolly]

On 18 October 2010 12:56, Ryan Schmidt  wrote:
>
> On Oct 18, 2010, at 06:42, Andrew Roughan wrote:
>
>> Porting the full svn client to my environment is not something I am willing 
>> to undertake myself.
>> So as an alternative I wanted to implement some Quick & Dirty interface over 
>> HTTP hopefully with a cleartext password.
>> Is there a document that describes the http interfaces to svn server for 
>> each function?
>
> Subversion uses many other libraries to get its job done, including apr and 
> apr-util, expat, neon or serf, sqlite and others, and Subversion is itself 
> divided into several libraries that carry out the various tasks. I think if 
> the Subversion developers could have might Subversion lighter, they would 
> have, and I don't think you will be able to make any such "quick and dirty" 
> client without having to reimplement most of Subversion, which, as you may 
> know, represents ten years worth of work.
>
> What is this mysterious environment you have where Subversion does not 
> already run?
>
> To answer your question, the Subversion HTTP interface is WebDAV, so you can 
> read up on that.
>
>

That depends on what you want that client to do if all you are
after is to fetch the head revision and you are not interested in
modifying the repo, then you could have a fairly light client using
just a http client lib

if you want to check stuff back in then you might be able to get
somewhere with DAV support which could be handled though http requests
quite simply, but you'd be loosing out on lots of good
functionality...

It would be possible to get a smaller client, if you only need to
support a smaller set of use-cases...

-Stephen

can not delete folder because lock

[netvampire.tw]

Dear
    I use Subversion 1.6.13 recently, we want to delete a folder but fail.The 
error message said there is a file name  is locked by someone. try to 
release lock or steal lock.
But the file already didn't exist. So we can not lock it. what happened to us?
How could we do? thanks.~
Best regards,
EdwinTai

Re: Subversion equivalent to VSS diff for binary files

[Daniel Shahaf]

(didn't read it all very very carefully; was too long for that)

David Weintraub wrote on Mon, Oct 18, 2010 at 09:47:32 -0400:
> Text files are stored as diffs and removing a particular
> revision of a text file won't save a lot of room in the repository.
...
> However, binary files are a bit different. Changing one line in a file
> and then compiling it may cause a cascade of changes, so the resulting
> difference between the previous revision of the binary and current
> version of the binary are quite huge.
> 

Seems to me the solution is "Don't store your binaries in Subversion".

What does storing the binaries in Subversion gain? (as opposed to
storing all historical binaries in FTP somewhere)

> In fact, Subversion can, unlike many version control systems, actually
> distinguish between binary types [...].
> 

What are you referring to?

Re: can not delete folder because lock

[Ryan Schmidt]

On Oct 18, 2010, at 09:14, netvampire.tw wrote:

> I use Subversion 1.6.13 recently, we want to delete a folder but fail.The 
> error message said there is a file name  is locked by someone. try to 
> release lock or steal lock.
> But the file already didn't exist. So we can not lock it. what happened to us?
> How could we do? thanks.~

Yes, there is a bug or unexpected feature that Subversion allows locked files 
to be deleted but does not remove the locks.

This was discussed once before, here:

http://old.nabble.com/Zombie-files-prevent-me-from-re-adding-deleted-file-td20210870.html

The above thread references a contributed script you can use to clean up these 
forgotten locks.

Re: Subversion equivalent to VSS diff for binary files

[Ryan Schmidt]

On Oct 18, 2010, at 09:25, Daniel Shahaf wrote:

>> However, binary files are a bit different. Changing one line in a file
>> and then compiling it may cause a cascade of changes, so the resulting
>> difference between the previous revision of the binary and current
>> version of the binary are quite huge.
> 
> Seems to me the solution is "Don't store your binaries in Subversion".

The resulting difference MIGHT be quite huge, but it doesn't have to be. It 
depends entirely on the particular binary file format you're talking about.

Re: Subversion equivalent to VSS diff for binary files

[Les Mikesell]

On 10/18/2010 9:25 AM, Daniel Shahaf wrote:

(didn't read it all very very carefully; was too long for that)

David Weintraub wrote on Mon, Oct 18, 2010 at 09:47:32 -0400:

Text files are stored as diffs and removing a particular
revision of a text file won't save a lot of room in the repository.

...

However, binary files are a bit different. Changing one line in a file
and then compiling it may cause a cascade of changes, so the resulting
difference between the previous revision of the binary and current
version of the binary are quite huge.



Seems to me the solution is "Don't store your binaries in Subversion".


Or at least binaries that can be rebuilt exactly from the 
version-controlled source.



What does storing the binaries in Subversion gain? (as opposed to
storing all historical binaries in FTP somewhere)


If you put them somewhere else you have to re-invent conventions to 
describe (in both directions) where to find the source/binaries that go 
together - and perhaps write your own authentication/permissioning 
mechanism to enforce them.  The main disadvantage of putting them back 
in subversion is that they will most likely be obsolete after a few new 
builds and there's no handy way to remove them or reclaim the space they 
consume.


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

UTF8 BOM Merge

[Vojáček Aleš]

May be i will be better to post mail with better subj. then use older one, so I 
will try.

Hi all,
Another problem with UTF, now it is problem when merging 2 files which are UTF8 
(BOM) The file on local HDD is still UTF8, but the file from repository is ANSI 
:-()
IdFromKodGenerator.cs.merge-left.r43343 - ANSI but in trunk (from I'm doing 
merge is UTF-8)
IdFromKodGenerator.cs.merge-right.r43356 - branch into I'm merging is UTF-8.

Can you help me with that?
A.

Re: Subversion equivalent to VSS diff for binary files

[David Weintraub]

On Mon, Oct 18, 2010 at 10:25 AM, Daniel Shahaf  wrote:
> Seems to me the solution is "Don't store your binaries in Subversion".
It all depends upon the binary file type and why you're storing it.

If your build uses GIFs and JPGs, you need to store binary files on
Subversion. And, Subversion has no problems with this.

Another example of storing binaries in Subversion? In my last job, our
help system used Robohelp which produced a wad of HTML files from a
Word document. Robohelp had to run on a PC while our builds were done
on Linux. Originally, we were attempting to store the resulting HTML
(mainly text) files on Subversion, but because Robohelp would
completely rebuild everything even with the most minor change, it
meant that the techwriters had to delete and add files hundreds of
files in Subversion with even the most minor technical document
changes.

I decided to simply have the techwriters zip up all the HTML stuff
into a single ZIP file and store that in Subversion. It made their
lives simpler, and it meant that svn log only showed a single file
change whenever the help was updated. That ZIP file was binary, but in
this case, it was worth storing it inside our repository.

But, storing your build output in Subversion? I'd argue it would be
questionable in ANY version control system simply because there are
better tools that can be used for this purpose.

For example, we use Hudson as our continuous build server. Our Hudson
process not only creates a new release with each and every check-in
(running Unit and Coverage tests), but it also stores the resulting
build. We setup Hudson to automatically delete most builds after a
certain period of time unless we mark them for QA or production. And,
as I just mentioned, we even mark builds in Hudson with their QA and
Production status. QA and System admins have no problem locating the
correct build to use.

You can even configure Hudson to use the results of Project A's build
in Project B. And, you can setup Hudson to automatically build Project
B whenever Project A rebuilds.

So, by using Hudson, there's no need to purge your revision control
system of obsolete binaries, your non-developers don't have to use a
revision control system just to get the files they want, and something
like Hudson automatically handles tracking build status for you.

By the way, my actual preference for a release Repository is either
Nexus or Artifactory. They provide a well documented (and open way)
way of doing the task which means I'm not tool dependent. Yes, they're
Maven repositories, but I find them just as effective for non-Maven
projects.

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

Re: Implementing lightweight client over http. Where to start?

[Andrew Roughan]

On Mon, Oct 18, 2010 at 12:56 PM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

>
> What is this mysterious environment you have where Subversion does not
> already run?
>

Apple IIgs with a 1Mz 65816 processor (or faster with accelerators and
emulators).
Yes there is a C compiler, but abysmal performance is likely to be an issue.

On Mon, Oct 18, 2010 at 2:51 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> That depends on what you want that client to do


I don't intend to fully implement all functionality. I want to be able to
checkout and commit.

I will look into WebDav support a bit more. I've read a few more webdav
notes and found the references to RFCs.

Thanks,
Andrew

Re: Implementing lightweight client over http. Where to start?

[Ryan Schmidt]

On Oct 18, 2010, at 10:47, Andrew Roughan wrote:

> On Mon, Oct 18, 2010 at 12:56 PM, Ryan Schmidt wrote:
> 
>> What is this mysterious environment you have where Subversion does not 
>> already run?
> 
> Apple IIgs with a 1Mz 65816 processor (or faster with accelerators and 
> emulators).
> Yes there is a C compiler, but abysmal performance is likely to be an issue.

Applause! :) Best of luck with this project.

Perhaps you can make use of some existing work:

http://www.whatisthe2gs.apple2.org.za/subversion/

More seriously, since the Apple II operating system isn't related to UNIX it 
may be difficult to get APR ported to it, but that would be the library to 
start with.

Having a path name after specifying repository location

[Tech Geek]

Hi,

My repository path is /var/lib/svn for the SVN server. However I encountered
a unique situation as follow:

The following works:
#svnadmin create  /var/lib/svn/projectA

>From a svn client:
#svn co http://svnserver/svn/projectA projectA


However the following does NOT work:
#mkdir /var/lib/svn/projectB/
#sudo svnadmin create  /var/lib/svn/projectB/partA
 #sudo svnadmin create  /var/lib/svn/projectB/partB

>From a svn client:
#svn co http://svnserver/svn/projectB/partA partB

Is it true that all the directories directly under /var/lib/svn/ should be
an *actual* repository? Can't we have some pathname like "ProjectB" under
/var/lib/svn/ and then have repositories (like PartA and PartB) under it
without changing the root path of the repository which is /var/lib/svn?

How do you overcome this situation? I want PartA and PartB to be separate
SVN repository but I do not want to place them under /var/lib/svn/ directory
because they beloing to ProjectB and in future other projects like ProjectD
could have PartA and PartB in the same manner.

Thanks.

Re: Having a path name after specifying repository location

[Tech Geek]

oops...I had a typo:


> However the following does NOT work:
> #mkdir /var/lib/svn/projectB/
> #sudo svnadmin create  /var/lib/svn/projectB/partA
>  #sudo svnadmin create  /var/lib/svn/projectB/partB
>
> From a svn client:
> #svn co http://svnserver/svn/projectB/partA partB
>

 However the following does NOT work:
#mkdir /var/lib/svn/projectB/
#sudo svnadmin create  /var/lib/svn/projectB/partA
 #sudo svnadmin create  /var/lib/svn/projectB/partB

>From a svn client:
#svn co http://svnserver/svn/projectB/partA partA

I get the error message: SVN: Could not open the requested filesystem.

Re: svn Farm

[Nico Kadel-Garcia]

On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
 wrote:

> Add a capability called "keyringenabled" to Subversion and now Nico
> will probably be much happier... but of course he doesn't trust his
> users so he cannot trust that they report "keyringenabled"
> correctly... but he might be pragmatic enough to accept that as a
> compromise.

Now, now. Don't put words in my mouth. I'm concerned about obvious and
possible and documented attack vectorrs: passwords in cleartext are
one of them. Eventually, any idiot can write a script that stores
passwords in clear-text to mishandle local passwords or passphrase
protected keys, but putting the capability in as the default behavior
is extremely poor practice and should not be supported by default
configuration or behavior.

I don't think that "keyring enabled" is sufficient. A protocol shift
that *requires* a better protected password and blocks the currently
unsecured local password storage access would be interesting, I
thought the gpg-agent changes would do that, but Stefan pointed out
the flaws, dang it.

svn+ssh actually works reasonably well: it just doesn't suppor the
"use my normal login password" approach to managing user access.

> and that's probably a feature we could add in 1.6.14 with only minor
> effort (most of the work being deciding what the feature name should
> be ;-) )
>
> -Stephen

If it could require the client to actually *use* the keyring, I could
see it. How would we support that for TortoiseSVN clients?

Re: can not delete folder because lock

[netvampire.tw]

It works fine.I use Tortoisesvn did it.
Thanks. So the bug didn't fix until now?
- 原始信件 
寄件者： Ryan Schmidt 
收件者： netvampire.tw 
副　本： users@subversion.apache.org
寄件日期： 2010/10/18 (一) 10:29:23 PM
主　旨： Re: can not delete folder because lock


On Oct 18, 2010, at 09:14, netvampire.tw wrote:

>    I use Subversion 1.6.13 recently, we want to delete a folder but fail.The 
> error message said there is a file name  is locked by someone. try to 
> release lock or steal lock.
> But the file already didn't exist. So we can not lock it. what happened to us?
> How could we do? thanks.~

Yes, there is a bug or unexpected feature that Subversion allows locked files 
to 
be deleted but does not remove the locks.

This was discussed once before, here:

http://old.nabble.com/Zombie-files-prevent-me-from-re-adding-deleted-file-td20210870.html


The above thread references a contributed script you can use to clean up these 
forgotten locks.

Users cannot reliably view SVN log messages remotely

[Shaun Pinney]

Hi all,

I've got a distant user who cannot reliably view the SVN log messages
Using TortoiseSVN.  If he 'refreshes', he can view the SVN log messages
fine.  Also, checkouts work fine.  Other users at his (distant) site
seem to have the same issue, but I can't reproduce the issue here and
haven't heard of similar issues from other sites.  We're using Apache,
and I did notice that the Apache logs occasionally shows the below errors
and wonder if there is a known explanation or solution:

Provider encountered an error while streaming a REPORT response.  [500, #0]
A failure occurred while driving the update report editor  [500, #103]
Error writing base64 data: Software caused connection abort  [500, #103]

I've checked the Subversion FAQ, and think the fix there does not apply
since my users are on Windows.  Does anyone know how to resolve these
errors?  I'm suspecting a network issue, so my next thing to try is to
increase the Apache timeout in httpd.conf.  My hunch is that this won't
solve the issue, so if anyone has additional ideas to try I'd really
appreciate it.

Thanks!
Shaun

RE: Users cannot reliably view SVN log messages remotely

[Shaun Pinney]

> I've checked the Subversion FAQ, and think the fix there does not apply
> since my users are on Windows.  Does anyone know how to resolve these

(...Sent this out too quickly... I meant to say:)
We're not serving from a MacOS X 10.4 machine, so I don't think the FAQ
applies here.

Re: can not delete folder because lock

[Ryan Schmidt]

On Oct 18, 2010, at 22:24, netvampire.tw wrote:

> So the bug didn't fix until now?

I guess not.

It might be this bug:

http://subversion.tigris.org/issues/show_bug.cgi?id=2507