How do I enforce a minimum client version when hosted via httpd

[Stephen Connolly]

I remember reading before about a hack/trick that allows you to ensure that
the client is at least mergeinfo aware when the repository is served via
Apache httpd.

Google is not being co-operative with my attempts to find the Apache HTTPD
directive that makes this magic happen.

IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients
from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall
it being about querying the capabilities of the client and a specific
capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow
blocking clients less than 1.6.13 from connecting ;-)

Anyway, if somebody could point me to the trick it would be much appreciated

-Stephen

Re: How do I enforce a minimum client version when hosted via httpd

[Stephen Connolly]

That was the trick I was looking for.  Thanks

On 7 October 2010 10:25, Ryan Schmidt  wrote:
> On Oct 7, 2010, at 03:29, Stephen Connolly wrote:
>
>> I remember reading before about a hack/trick that allows you to ensure that 
>> the client is at least mergeinfo aware when the repository is served via 
>> Apache httpd.
>>
>> Google is not being co-operative with my attempts to find the Apache HTTPD 
>> directive that makes this magic happen.
>>
>> IIRC the trick is less than perfect, i.e. it just blocks < 1.5.2 clients 
>> from connecting (though the version limit could be 1.5.0 or 1.5.1 I recall 
>> it being about querying the capabilities of the client and a specific 
>> capability was only introduced in 1.5.1 or 1.5.2) A better trick would allow 
>> blocking clients less than 1.6.13 from connecting ;-)
>
> There is no Apache directive for this; instead, you can write a clause in 
> your start-commit hook script. From the start-commit.tmpl file created for 
> you in every new repository:
>
>
> #   [1] REPOS-PATH   (the path to this repository)
> #   [2] USER         (the authenticated user attempting to commit)
> #   [3] CAPABILITIES (a colon-separated list of capabilities reported
> #                     by the client; see note below)
> #
> # Note: The CAPABILITIES parameter is new in Subversion 1.5, and 1.5
> # clients will typically report at least the "mergeinfo" capability.
> # If there are other capabilities, then the list is colon-separated,
> # e.g.: "mergeinfo:some-other-capability" (the order is undefined).
>
>
> So if the third parameter passed to your start-commit hook script is empty / 
> nonexistent, you know that client is older than 1.5 and you can take some 
> action, such as denying the commit, if that's what you want to do.
>
>

Re: Repository organization for complex project

[Stephen Connolly]

On 13 October 2010 19:19, David Weintraub  wrote:
> On Wed, Oct 13, 2010 at 1:42 PM, Les Mikesell  wrote:
>> How would you access them if you don't have java/maven/ivy when you want to
>> retrieve a certain version?
>
> Before we adopted our Ant projects to use Maven, we simply used the
>  task. You can always download from a Maven repository using the
> "get" and "wget" commands. Maven repositories, after all, are HTTP
> accessible. There's no real reason why you can't user wget and curl to
> do the fetching if you aren't a Java shop.
>
> Uploading is trickier though. We simply used a shell script that
> generated the correct "mvn install-file" command and didn't have to
> generate a POM. Maven and Java are fairly easy to install and use open
> source licenses, so there isn't really a big deal to install them.
> With the "mvn install-file", we didnt' even have to create a pom.xml
> file. We could build the command on the fly with just a shell script.

Our C/C++ guys just use curl to POST the binaries to Nexus over
http... we also POST the .pom file and the .md5 and .sha1 files...
that is because one of their build toolchain envs cannot have Java on
it... Nexus will rebuild the metadata.xml files for you, so all you
really need is to post the .pom and the e.g. .so and the .pom.md5,
.pom.sha1, .so.md5 and .so.sha1 files and you're done.

If you have a java install on the system, use maven or maven-ant-tasks
(from ant) or ivy (from ant) to do the post for you.

I think I had a set of bash scripts somewhere in
http://svn.apache.org/repos/asf/maven/sandbox/trunk/ at some time.
I'll see if I can find them

>
> But, there's really no reason that you HAVE to use a Maven repository.
> All you need is a remote storage directory and the concept of version
> numbers. I'd setup the repository to use Mavenish concept of object
> with sub-directories for each release and embedd the release into the
> object between the object's name and suffix. For example, if Project B
> produced a library libprojb.so, I'd call the thing libprojb-3.2.so,
> and store it in my projectb/3.2 directory.
>

The advantage of a Maven repository is that you can use a Maven
Repository Manager to enforce some good things, such as write-once,
authorization and search... but there is nothing stopping you from
just copying everything to a big file share in the sky!

> Imagine if you take the approach of checking into your repository the
> libprojb.so library for Project A to use. What usually happens is that
> you have a lib directory under your project with a libprojb.so
> directory in it. You have no idea what files went into this directory
> or what version it was from. Two years from now, that libprojb.so
> directory will still be there and no one will know anything about it.
>
> However, imagine if in Project A's make file is a macro
> PROJB-LIB=projb/3.2, and later on, it uses this information to do a
> scp from the release repository. You can look at that particular
> version of Project A and say "Ah! It uses version 3.2 of Project B.
> Since we tagged the source code used for that version of Project B as
> 3.2, we can still trace down the correct version. And, we can see that
> the next release of Project A uses version 3.3 of Project B.
>
> --
> David Weintraub
> qazw...@gmail.com
>

Re: Repository organization for complex project

[Stephen Connolly]

On 13 October 2010 21:42, Les Mikesell  wrote:
> On 10/13/2010 2:52 PM, BRM wrote:
>>
>>> From: Les Mikesell
>>> We currently commit component binaries back into  tags which are then
>>> used by
>>> other things with external references, and final  binaries are managed
>>> separately by project, but that seems wrong on several  levels.
>>
>> For the projects we do nightly builds on we use an FTP site that the build
>> scripts upload the builds to. This is easy enough to script even on
>> Windows -
>> whether using DOS Batch or Windows Scripting Host.
>> I'm sure Hudson and other build systems can handle that just fine.
>>
>>> I'd like to find a generic scheme (and one that can be plugged  into
>>> hudson if
>>> possible) to store build results with a versioning scheme that
>>>
>>> doesn't force you to keep them forever because most are obsolete after a
>>> few
>>> new  builds but that has a close-coupling to the svn version
>>> or at least the tag name  of the matching source.  But this seems like it
>>> should be a common scenario  and not something everyone re-invents
>>> differently.
>>
>> Well, right now I have a lot of projects that don't have a nightly build -
>> mostly due to how Qt and Visual Studios interact - or rather, the problems
>> in
>> doing so.
>> However, you can do a couple things to track this very well and
>> automatically,
>> partially supported via Subversion's Keyword Substitution.
>> I use $HeadUrl$ in a number of projects to get the URL, which I then parse
>> to
>> get a information about the build; for example, if it's a tag then I grab
>> the
>> release information, or a branch then I build a special branch info to
>> output.
>>
>> For things like the global revision number you'll need to use 'svnversion'
>> to
>> capture the output somehow.
>>
>> The following would probably work for you:
>>
>> 1. Capture the URL somewhere as part of checking it out using $HeadURL$
>> 2. As part of the build script run and capture the output of "svnversion",
>> you
>> might want to do so with "svn info" too - though this only works if you
>> are NOT
>> doing an export.
>>
>> You can then store these with a copy of the source and resulting binaries
>> to
>> have full traceability.
>> Alternatively, if you are using "svn co" in the build, just tarball or zip
>> up
>> the project's sandbox at the end of the build script and save it as a
>> whole -
>> this will keep ALL the information, URLs, versions, etc; for you - and is
>> very
>> build system friendly too.
>
> This covers the 'backtrack from binary' scenario as long as you keep those
> extra pieces in the zip with them.  But I'm looking more for a filesystem
> and/or http URL name/path mapping to store the binaries so you can easily
> find the currently relevant versions in the first place.

Use Nexus (A maven repository manager)

The backing store is on the file system.

It has a searchable interface that can be used over http to, e.g. get
the latest version (IIRC even the latest version within a range, e.g
[1.0,2.0) will ensure I never get any of the 2.0 artifacts)

It's very lightweight and almost trivial to install.

Oh and the open source edition is free! I've used the pro edition and
it's great but the OSS is fine for most use cases... the only thing I
miss from the pro is the staging support

-Stephen

P.S. I am just a happy Nexus user, I have no affiliation with Sonatype
at present.

> Among other things
> it should provide a straightforward way to replace our current svn externals
> to pull specific libraries into place for dependent builds, and also map to
> our branch/tag name structure for qa and production releases.  Maven may be
> the right answer, but I was thinking in terms of something that could be
> viewed as a filesystem - maybe like alfresco where additional rules can be
> imposed.
>
> --
>  Les Mikesell
>    lesmikes...@gmail.com
>
>

Re: Repository organization for complex project

[Stephen Connolly]

On 14 October 2010 22:03, Les Mikesell  wrote:
> On 10/14/2010 3:11 PM, David Weintraub wrote:
>>
>> What? You want a GOOD Maven manual? Real programmers don't use
>> manuals.
>
> Yeah, I know - they don't write them either (except for subversion, of
> course).  As you might guess, I'm more of a system administrator than a
> programmer...
>
>> Fortunately, you don't really have to know too much about Maven if
>> you're not a Java developer. The intricacies of the pom.xml file don't
>> concern you. Possibly, the only Maven command you really have to know
>> is "mvn deploy:deploy-file" which doesn't require a pom.xml file
>>
>> .
>> And, if that command concerns you too much, you can simply revert to
>> "curl".
>>
>> You do have to understand the Maven repository layout which is a
>> fairly straight forward hierarchal affair and both Nexus and
>> Artifactory cover that pretty well.
>
> Thanks - the piece I need is how to map our project tags and
> branch/revision_numbers into the maven repo URLs, hopefully in a way that
> wouldn't break it for actual maven use since we do have some java developers
> here.

every artifact in the maven repository has a set of coordinates, known
as GAV (though technically it is GAVCT)

GroupId:ArtifactId:Version[:Classifier]:Type

in the group id, you use reverse DNS name to establish ownership of
the namespace, dot's are replaced by slashes... so one project I am
working on at github uses the groupId
com.github.stephenc.java-iso-tools as the project url is
http://github.com/stephenc/java-iso-tools

I have other things where I use groupIds starting with com.one-dash
because I own the domain.

The artifactId can be whatever you like (within reason)

The version is a version number

The classifier is similar to artifactId and this is more for
side-artifacts... you probably don't want classifiers in most cases...
side-artifacts would be things like javadocs... try to keep one GAV
for one theing that you build, e.g. a separate GAV for the x86 and the
ARM versions of your build rather than abuse classifiers [so that you
play better with the java builds]

to consturuct the url

URL=${REPO_ROOT}/$(echo ${GROUP_ID} | sed -e
"s:\.:/:g")/$ARTIFACT_ID/$VERSION/$ARTIFACT_ID-${CLASSIFIER}-${VERSION}.${TYPE}

if you have a classifier and

URL=${REPO_ROOT}/$(echo ${GROUP_ID} | sed -e
"s:\.:/:g")/$ARTIFACT_ID/$VERSION/$ARTIFACT_ID-${VERSION}.${TYPE}

if you don't

-Stephen

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

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

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

Re: svn Farm

[Stephen Connolly]

On 19 October 2010 02:17, Nico Kadel-Garcia  wrote:
> 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.
>

the svn client would only report keyringenabled if the keyring was
enabled for password storage and the client was configured to not
store plaintext... perhaps "plaintextpasswordstoragedisabled" is a
better name for the feature.

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

Exposing the feature would not in an of itself force the client to use
the keyring, but it would allow the server to have a start-commit hook
that blocked a commit if the user had plaintext password storage
enabled...

so ok, if I have a client with plaintext storage enabled and I attempt
a commit, there is a possibility that my password will get stored in
plaintext on my system, but the start-commit hook can send back the
message saying something like "Your client is storing passwords in
plaintext, which is against the policy for this server.  To commit
your changes you need to configure your client to securely store the
password or else use --no-auth-cache on the command line. See
http://internal-wiki-page-link for details."

The wiki page can describe how to remove the plaintext passwords and
how to configure a keyring.

So you would not get completely secure by default, but one could have
the start-commit.tmpl have code to show how to secure the system, and
you would have what you require to ensure the system is secure going
forward.

-Stephen

Re: svn Farm

[Stephen Connolly]

On 19 October 2010 10:18, Johan Corveleyn  wrote:
> On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly
>  wrote:
>> Exposing the feature would not in an of itself force the client to use
>> the keyring, but it would allow the server to have a start-commit hook
>> that blocked a commit if the user had plaintext password storage
>> enabled...
>
> Just keep in mind that alerting users with start-commit hook only
> works for users that actually commit of course. You won't reach users
> that merely checkout/update/log/blame/...

true, but that assumes you require authentication to have read access.

we do not require authentication for read, only for write

>
> It might be a better solution to implement this check in a lower
> level, in the ra-protocols (naïvely, e.g. with http(s): client sends
> with every request a header announcing the way it stores its
> password). Of course, you'd like to do this without adding too much
> overhead (handshaking, ... for every tiny request that the client
> makes to the server). Maybe there is already some functionality
> present for protocol/feature negotiation, I don't know ...
>
> Just my 0.02€
>
> Cheers,
> --
> Johan
>

I agree that this would be better!

-Stephen

Re: Determine the date / time of remote SVN server from the command line?

[Stephen Connolly]

2010/10/19 Olivier Mengué :
>
>
> 2010/10/19 Michael March 
>>
>> Hey,
>> Does anyone out there know  if  there is a way to determine the date /
>> time of remote SVN server from the command line?
>
> As a SVN server is an HTTP Server you can use any HTTP tool to check the
> "Date" header.
> For example, with curl :
>
> $ curl -I http://svn-graph-branches.googlecode.com/svn/trunk/ | grep ^Date:
> Date: Tue, 19 Oct 2010 09:11:33 GMT
>
>

Only works if you are serving the repo over http / https if serving
over svn+ssh or svn then you might not have the same luck

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

[Stephen Connolly]

Have you considered doing a binary search to find the revision that it was
deleted in?

svn ls .../t...@2
Exists
svn ls .../t...@head
No such file in revision 50002
svn ls .../t...@25002
Exists
svn ls .../t...@37502
No such file
svn ls .../t...@31252
Exists, etc

You'll get the revision in at most log2 HEAD iterations

- Stephen

---
Sent from my Android phone, so random spelling mistakes are a direct result
of using swype to type on the screen

On 28 Nov 2010 06:30, "Andrey Repin"  wrote:

Greetings, Les Mikesell!


>>> The change for that rev happened in the directory above.
>>
>> I'm looking for directory alread...
Wat? It start with HEAD irrelevant to what PEG revision we've specified.
And immediately spitting "no such file", although the file is 100% there.


> of the revision before the delete and the log will track it back
> through it's entire history.
...
I specified PEG revision. Documentation clearly states that PEG revision has
precedence over operative revision in conflicting names resolution, but for
absent files (name conflicting with void) it not seems to be the case.


 I can understand that it's not easy to track deletes/copies forward,
but
 tracking history...
Yes, but it's still a deletion.


> The log of the renamed file will have it, as will the directories
containing
> the changes to the...
Unfortunatelly. It only show that file was renamed, but does not show the
new
name. (Or old name? One of them - see the log below)


>>> It is not that it isn't tracked. It just isn't tracked where you are
looking
>>> for it.
>>
>>...
I beg to differ.
I'm asking to
1. Pick the file (directory) /test at revision 2
2. Track it's changes history from revision 0 to HEAD.
3. I'm fully aware that the directory does not exist in HEAD, neither I ask
Subversion to look there in first place. (literal meaning of "first place")
4. Quite (un)surprisingly, my intent is to actually find revision, in which
the destruction was made. Because, quite (un)surprisingly, I don't know
that.

See the order of instructions? Do I need to refer to the svnbook chapter
discussing PEG and operative revisions, or you can find it yourself?


>> [C:\]$svn log -v -r 0:3 -- http://svn.darkdragon/repos/t...@2
>> ---...
I could have pointed to any other of the revisions between @PEG and HEAD,
which will net the very same result - unless I guess it right, the process
will not start at all.


> I guess it could be more polite about giving you the revisions it can find
> along with the error...
Nah, it could just obey to @PEG rule. Everything will be simpler.
Unless there's absolutely no other way to track the file from @PEG, which i
doubt, since you DO can access the file by @PEG, as well as navigate back in
time easier, than forward.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 28.11.2010, <9:13>


Sorry for my terrible english...

Re: "svnadmin load" a huge file

[Stephen Connolly]

Google is your friend: svndumptool

You moght need to append a .py

Also if this is a _top post_ it's three phone what done it... Haven't
figured out how to control where it puts the reply

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 31 Dec 2010 15:10, "Victor Sudakov"  wrote:
> Daniel Shahaf wrote:
>> Split the dumpfile to smaller dumpfiles
>
> How do I do that? I have not found such an option in cvs2svn.
> I don't mind writing a script if I knew the idea how to split the dump.
> I haven't found any "svnadmin load" option to import part of a dump
> either. man what?
>
>> or try a newer version of svnadmin.
>
> I am using subversion-1.6.15, it seems to be the latest ported to
> FreeBSD.
>
>>
>> (or dive into the source and help us plug that memory leak --- compile
>> with APR pool debugging enabled)
>
> I will try to do that but unfortunately I need some immediate
> workaround :(
>
> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru 

Re: On commit attempt, Server sent unexpected return value (403 Forbidden) in response to CHECKOUT

[Stephen Connolly]

a post-commit hook or a crontab coils update the file to keep the security
on newly created branches (top post a result of this stupid phone... sorry)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 3 Jan 2011 15:18, "Mark Phippard"  wrote:
> On Mon, Jan 3, 2011 at 10:13 AM,  wrote:
>> Wow...for some reason I was under the impression that file level
restrictions didn't work...I really don't know why, but there it is.
>>
>> I don't suppose there's a way to use wild cards in the path as well?
>
> Wild-cards are not supported in authz.
>
> If you only needed this to protect writes, then you can do it with a
> pre-commit hook. The SVN repository contains svnperms.py which can do
> this:
>
> http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/
>
> However, if you need to protect read access, you cannot do it via a
> hook and the Subversion authz module does not support wildcards.
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/

Re: "svnadmin load" a huge file

[Stephen Connolly]

On 10 January 2011 08:30, Michael Haggerty  wrote:
> On 01/07/2011 08:38 PM, Victor Sudakov wrote:
>> Daniel Shahaf wrote:
>>> I don't know cvs2svn, but it could have a --sharded-output option, so eg
>>> it would produce a dumpfile per 1000 revisions, rather than one huge
>>> dumpfile.
>>
>> cvs2svn-2.3.0_2 does not seem to have such an option:
>> "cvs2svn: error: no such option: --sharded-output"
>
> cvs2svn doesn't have such an option, but it wouldn't be very difficult
> to implement.  Let me know if you would like some pointers to help you
> get started implementing it.
>
> Michael

Hello... I said this a week ago

Split
-

Splits a dump file into multiple smaller dump files.

svndumptool.py split inputfile [startrev endrev filename]...

options:
  --version   show program's version number and exit
  -h, --help  show this help message and exit

Known bugs:
 * None


No need to go implementing anything

-Stephen
>
> --
> Michael Haggerty
> mhag...@alum.mit.edu
> http://softwareswirl.blogspot.com/
>

Re: Windows over linux

[Stephen Connolly]

windows has harsh file locking symmantics, choose linux.

(top post because android refuses to let me bottom post.. or let me know
what setting to tweak on froyo)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 25 Jan 2011 08:43, "Oliver Marshall" 
wrote:
> Hi,
>
> As far as subversion is concerned, is there any reason to go for one OS
over another when setting up a new subversion server? Are any of the hooks
or features OS dependant?
>
> Olly

Re:

[Stephen Connolly]

noo!

now nico will start his security rant again!

you have been warned ;-)

(note he may or may not have a point which matters to you, but it definitely
matters to him)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 25 Jan 2011 09:30, "Alexey Bakhirkin"  wrote:
>> Mind you, I highly discourage theh HTTP or HTTPS access to Subversion
>> due to the plain-text password storage issues for UNIX/Linux/CygWin
>> clients.
>
> IIRC 1.6 client can be configured to use gnome keyring or kde4 kwallet
> for Linux (
http://subversion.apache.org/docs/release-notes/1.6.html#auth-related-improvements
).
> Never tried that though.

Re: http + ssh

[Stephen Connolly]

you could use port tunnelling to make it look like an http repo on localhost
on a port other than 80

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 9 Feb 2011 20:43, "Ryan Schmidt"  wrote:
> On Feb 9, 2011, at 14:38, alexus wrote:
>
>> svn co svn+ssh://your.remote-server.com/home/svn/test
>>
>> is there a way to do something like this but without running
>> subversion daemon, because in my case I use svn through apache?
>>
>> but I need to use SSH as well
>>
>> so somehow http+ssh ?
>
> The available repository access methods are:
>
> file:/// (no server process; no encryption; for testing local repositories
only)
>
> svn:// (svnserve daemon always running or started on demand by initd or
launchd; no encryption)
>
> svn+ssh:// (svnserve started on demand by sshd; ssh encryption)
>
> http:// (apache httpd daemon always running or started on demand by initd
or launchd; no encryption)
>
> https:// (apache httpd daemon always running or started on demand by initd
or launchd; ssl encryption)
>
>

Re: svn externals

[Stephen Connolly]

oh I like that.

you could even allow the client config file to add custom uri schemes and
the path to the exec that handles them

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Feb 2011 18:23, "Ryan Schmidt" 
wrote:

Re: svn externals

[Stephen Connolly]

yeah, but you'd want at least an option for the client to override ;-)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 14 Feb 2011 07:12, "Ryan Schmidt" 
wrote:

Re: svn externals

[Stephen Connolly]

because you might not want the git on the system path

because you may not have permissions on windows to set the uri handler

just two, there's more

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 14 Feb 2011 07:59, "Ryan Schmidt" 
wrote:
>
> On Feb 14, 2011, at 01:57, Stephen Connolly wrote:
>
>> yeah, but you'd want at least an option for the client to override ;-)
>
> Why would one want that?
>
>

Re: problem with mutated vowel in log-message-contents

[Stephen Connolly]

unix shell scripting could solved it for you

bash
for rev in $(svn log ... | sed -n -e "..."); do svn ps --revprop svn:log
"$(svn pg svn:log -r $rev | sed -e "s/oldstring/newstring/g;")" ... ; done

I leave the ...'s as an exercise to tgeur reader

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 18 Feb 2011 13:16, "Thomas STEININGER"  wrote:
> i need a tip to solve my problem with log-messages in our
> subversion-repository. (see the mail-conversation with the tortoisesvn
> team below).
> there are message that contain mutated vowel and i need to find all them
> and correct them.
> f.e. i want to replace 'übergabe' by 'uebergabe' or if this is to
> difficult only by '_bergabe'.
>
> can anybode give me tips / commands to do that or probably there is an
> tool (because the problem was already solved for another user)?
>
> thanks for help
> -thomas
>
> Mails with TortoiseSvn-Team:
>
> Hello i have an really *big problem *using tortoise-svn.
>
> The same problem has - by the way - eclipse-subversive with
> javahl-connector, but not with svnkit-connector.
>
> if i try to show the logs of ein entry/file/.. in tortoisesvn where
> the
> log-messages contain a mutated vowel (german: deutscher umlaut)
> then it brings an failure msg:
>
> and then it shows
>
> instead of the messages.
>
> can anybody help?
> Thomas

log messages must be in utf8 encoding. That's a requirement of the svn
library. If they're not, then anything can happen. For example if you
access the repository with http(s), then those messages have to be sent
>
in an xml response, and non-utf8 strings result in invalid xml.

When you commit with TSVN, TSVN ensures the encoding. But it might be
that other svn clients have a bug and don't properly encode the log
messages. In that case you have to fix the repository on the server
directly using the command line tools (svnadmin).

Stefan
>>>we already want to correct the log-messages, but we did not find an way
> to
>>>get all the log messages with failures and then to correct them.
>>>is there a known way - a tip to help us?
>>>
>>>thanks
>>>thomas
>>>
>>You have to ask for help with this on the Subversion users list. This is
>>an issue with the server/repository, not with TSVN and you'll get much
>>more help about this over there.
>>
>>Stefan
>>
>
>
>
> Der Austausch von Nachrichten mit o.a. Absender via e-mail dient
ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen
über dieses Medium nicht ausgetauscht werden.
>
> Correspondence with a.m. sender via e-mail is only for information
purposes. This medium is not to be used for the exchange of legally-binding
communications.

Re: problem with mutated vowel in log-message-contents

[Stephen Connolly]

bash will handle the multiline in my case (try and see) but your example
will handle if log contains "

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 21 Feb 2011 07:18, "Lorenz"  wrote:
> Stephen Connolly wrote:
>>unix shell scripting could solved it for you
>>
>>bash
>>for rev in $(svn log ... | sed -n -e "..."); do svn ps --revprop svn:log
>>"$(svn pg svn:log -r $rev | sed -e "s/oldstring/newstring/g;")" ... ; done
>
> svn:log may be multi-line ...
>
>
> ... but
>
>> svn pg svn:log --revprop -r $rev $url | sed ... | svn ps svn:log
--revprop -r $rev --username ... --password ... --file - $url
>
> should do it (... == fill in the blanks 8-)
> --
>
> Lorenz
>

Re: possible to have a local log instead of going to use svn log and going to site when checking a repo.

[Stephen Connolly]

git-svn

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 15 Jun 2011 07:17, "Ryan Schmidt" 
wrote:
> On Jun 14, 2011, at 22:53, shirish शिरीष wrote:
>
>> Is it possible to check out the log as well when you are checking out
>> a version from some repo.
>
> [snip]
>
>> I know I could do something like this :-
>>
>> svn log > svnlog150611.txt
>>
>> This would download the log file and put the contents in some text
>> file I have named as svnlog150611.txt . The problem with this way of
>> doing things is that each time I have to check out I would have to
>> create a new txt file with that date.
>
> [snip]
>
> There isn't a built-in way to do this.
>
> One solution would be to write a script, which does "svn update" or "svn
checkout" and also gets the log for you and saves it in a file. You would
then train yourself to use that script instead of running "svn update" or
"svn checkout" directly.
>
> The other way would be for you to run your own mirror of their repository,
using svnsync, possibly even on the same computer where you're going to be
checking out these working copies. You would then check out from your
mirror, not the main repo. You could then run "svn log" and it would access
your own repo, not theirs, and so would be usable even when you're offline.
The penalty is that you would have to periodically svnsync their repository
to yours, so you wouldn't be completely up to date between syncs. But
depending on your needs that might be ok.
>
>
>

Re: RE: Releasing an open source subversion client

[Stephen Connolly]

perhaps they are writing a new java client under a more friendly license
than svnkit... otherwise yeah i agree that it smells like a complete waste
of time and effort.

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 5 Aug 2011 15:05, "Bob Archer"  wrote:
>> Hi Subversion,
>>
>> I'm Rajith Chathunga from university of Moratuwa, Sri Lanka. My team is
>> developing an open source Subversion client as our internship project. It
will
>> be a great help that you can provide us some directions to release it.
What is
>> the procedure that we should follow to release it?
>>
>> Thank you.
>
> If you are going to put a whole team of devs to work on svn why not work
with the current svn team to identify a feature for the current 1.7 client
to implement. There is tons of stuff on the 1.7 list that got pushed off to
1.8. Or work with the TortoiseSVN team to add a feature to that product if
you are working in windows.
>
> I just don't see why you want to create YASC.
>
> BOb
>

Re: Request for thoughts on working copy enhancement request

[Stephen Connolly]

Sounds like a feature much like git's "git stash"

On 21 December 2011 20:10, Randon Spackman  wrote:
> One of my common use cases for subversion is to want to split my changes
> into two separate commits.  In the past, I would do the following:
>
>
>
> 1)  Check out
>
> 2)  Make changes
>
> 3)  Realize that this should be more than one commit
>
> 4)  Copy directory “MyCode” to “MyCode2”
>
> 5)  Revert changes I don’t want to commit yet from “MyCode2”
>
> 6)  Commit “MyCode2”
>
> 7)  Delete “MyCode2”
>
> 8)  Update “MyCode”; already committed changes are merged and no longer
> appears as diffs.
>
> 9)  Commit remaining changes in “MyCode”
>
>
>
> Unfortunately, this use case is defeated by the 1.7 changes to a single .svn
> dir.  My current workarounds are as follows:
>
> 1)  Copy the entire working copy (multiple GBs, waste of time), or
>
> 2)  Do an “svn info” to get repo and revision, then check this out
> somewhere to obtain the necessary “.svn” folder which is then copied to
> “MyCode”.
>
>
>
> Neither of these is very elegant.  I’d like to see a new svn command such as
> “svn localize” (don’t keep my terminology if it sucks) that would make the
> directory you specify its own independent working copy that can be copied
> and manipulated individually, and possibly a “svn delocalize” to reintegrate
> it.  (Although this can be accomplished less effectively by simply deleting
> the “.svn” directory and doing an update.)
>
>
>
> Is there already a way to do this?  Thoughts?
>
>
>
> Randon Spackman

Re: Merging repositories => UUID conflict

[Stephen Connolly]

On 15 October 2012 15:08, Jan Keirse  wrote:

> Hello,
>
> we currently have multiple repositories but want to merge all of these for
> various reasons but am running into a problem.
> Here's what we have now:
> Repositories A and B, they have no paths in common, except for /, because
> repository A has /trunk, /branches, /tags while B has
> /project[x]/branches,...
> What I tried is to svnadmin dump B and svnadmin load it into A. Obviously
> the revision numbers are different but otherwise everything is there and
> this appears to be a good sollution.
> However, when I try to svn relocate the working copies from repository B
> to repository A because the UUID is different between the 2 servers. I had
> hoped I would be able to just relocate and after an update svn would see
> nothing changed between the version number increase and just accept it.
>
> I now have 2 questions I can't seem to find an answer to:
> - Is there a way to merge the repositories without having to checkout all
> working copies again? I only found references to how to do it by editing
> the metadata of the working copy with sqlite but that just doesn't sound
> like a healthy path to choose.
> - Is the concept of dumping a repository and loading into another
> repository that already have revisions something safe? Or is this risky
> (one odd thing that's instantly visible is that revisions with high numbers
> can be older than revisions with lower numbers?)
>
>
http://stackoverflow.com/questions/267256/combining-multiple-svn-repositories-into-one

Should answer your questions...

There is only one issue with the suggested approach, namely that the dates
in the repository will not be strictly increasing so date range searches
will be broken.

There is a different tool that can merge and keep the dates in order:

https://github.com/jwiegley/svndumptool

But I have had issues with dump file format. Last time I tried the dump
files were in a format that was too old/new (cannot recall which) for the
merge code in svndumptool and I was fed up and just said "feck it" and
appended the revisions onto the end (causing the date-range issue). What I
should have done is imported the dump files into the correct version of
svn, re-dumped and then used svndumptool... in retrospect if I had to do it
again that is exactly what I would do, but at the time I had just spent 1
month converting 80 repositories from Accurev to Subversion and this last
repository was one where I was trying to merge the head of the rebel
developer's subversion work onto the tail of the accurev repo they gave up
on and then merge in the second svn repo they used in parallel... Glad I
don't work for that company any more ;-)


>
> Kind Regards,
>
> *JAN KEIRSE*
> *CORPORATE SERVICES* • *Specialist Software Developer*
> T +32 56 43 42 45 • F +32 56 43 44 46 • jan.kei...@tvh.com
>
> *TVH GROUP NV*
> Brabantstraat 15 • BE-8790 WAREGEM
> T +32 56 43 42 11 • F +32 56 43 44 88 • www.tvh.com
>
>

Re: Number of directories which can be stored in SVN

[Stephen Connolly]

There are a number of rather big repositories out there, e.g.

svn.apapche.org - nearing 1 million revisions in the asf repo... and there's
plenty of files in that one too

You'll probably run out of disk space before you hitany arch limits in
subversion

-Stephen

On 25 February 2010 21:59, Ryan Schmidt wrote:

>
> On Feb 25, 2010, at 14:53, Sandeep Kuttal wrote:
>
> > I am a PhD student at UNL, NE. For my project I am planning to use SVN
> but to check the scalability of the project i need to find out how many
> files and directories can be stored in subversion.
>
> As David said, I don't think there's a limit. I believe there are some
> performance problems you may run into if you try to put thousands of files
> into a single directory.
>
>
>

Re: Locking in Subversion

[Stephen Connolly]

On 9 March 2010 16:20,  wrote:

>
> Hi Guys,
>
> Please can you advise me on below.
>
> I have been asked to configure Subv in a way that all word docs/newly added
> docs are configured for needs-lock in a particular projecy (say Project A)
> under a repository.
>
> Initially I tried to implement this by adding below property to my Subv
> config file
>
> *.doc = svn:needs-lock
>
> But this affects other projects under different repo as the settings is
> machine specific.
>
> Is there a way, I can add a property to apply needs-lock to files under a
> specific project in a repo.  As there are 100 of such word docs, I wanted to
> avoid setting it at each file level.
>
>
Put a pre-commit hook that checks for any attempts to commit a .doc file to
the repo where that .doc file does not have the svn:needs-lock property set
and bombs out the commit with an error stating that the property needs to be
set for .doc files and pointing people to a how-to doc explaining how to
setup their autoprops config to do this for them

-Stephen


> Please let me know if you need any more information on this.
>
> **
> This email is confidential and may contain copyright material of the John 
> Lewis Partnership.
> If you are not the intended recipient, please notify us immediately and 
> delete all copies of this message.
> (Please note that it is your responsibility to scan this message for 
> viruses). Email to and from the
> John Lewis Partnership is automatically monitored for operational and lawful 
> business reasons.
> **
>
> John Lewis plc
> Registered in England 233462
> Registered office 171 Victoria Street London SW1E 5NN
>
> Websites: http://www.johnlewis.com http://www.waitrose.com 
> http://www.greenbee.comhttp://www.johnlewispartnership.co.uk
>
> **
>
>
<>

Re: subversion failover

[Stephen Connolly]

On 22 March 2010 16:21, west alto  wrote:

> Hi,
>
> Any one tried High Availability with subversion, using Apache,
> Heartbeat and NFS? Is this possible? any problems encountered?
>
> My requirement doesn't need to be load balance, I just want that when
> my primary subversion server is down my secondary server would be up.
> Does not need to be realtime, but needs to be auto failover.
>
> Any suggestion?
>
>
We are successfully using (mostly) the above.

We have Apache, Heartbeat and we use DRBD to mirror the SVN filesystem

Great failover support...

We had off-site write-through mirroring until somebody lost the server we
were using as a backup in the US ;-) [note to self, send somebody looking
for that server to turn it back on again]


> Thanks,
>
>
> West
>

Re: Where should I start, if I want to build the SVN project?

[Stephen Connolly]

On 12 April 2010 03:48, Saiho Yuen  wrote:

> HI,
>
> I wish to build a custom GUI for SVN with Java. And I wish to learn from
> the start, so I would like to learn how to build the SVN project form the
> source codes. So can someone please tell me where can I get the
> documentation? I'm working on Vista, should I use the MS Visual Studio or
> another compiler or do I need other softwares?
>
> thanks you very much
>
> Saiho
>
>
If you are writing the GUI in Java you might be better off using the SVNKit
libraries as that way you will not have to deal with JNI.

Google is your friend for finding things

-Stephen

Re: Where should I start, if I want to build the SVN project?

[Stephen Connolly]

Well fine then. what I meant to say is:

"You have exhausted the amount of help you will get from me on this topic,
so don't send me personal emails asking for more help because you will not
get it"

On too many occasions I reply to a post only to have the original questioner
decide that I must therefore be the "expert" on the topic that I replied
to... actually that is not the case, I gave you all the pointers I have at
the moment, and emailing _just me_ with more questions will only delay you
getting the answer, especially when Google searches can give better answers
than me

;-)

-Stephen

On 12 April 2010 11:58, Justin Connell  wrote:

>  *Google is your friend for finding things
>
> *
> There is no need for facetiousness..
>
>
> Stephen Connolly wrote:
>
> On 12 April 2010 03:48, Saiho Yuen  wrote:
>
>>   HI,
>>
>> I wish to build a custom GUI for SVN with Java. And I wish to learn from
>> the start, so I would like to learn how to build the SVN project form the
>> source codes. So can someone please tell me where can I get the
>> documentation? I'm working on Vista, should I use the MS Visual Studio or
>> another compiler or do I need other softwares?
>>
>> thanks you very much
>>
>> Saiho
>>
>>
> If you are writing the GUI in Java you might be better off using the SVNKit
> libraries as that way you will not have to deal with JNI.
>
> Google is your friend for finding things
>
> -Stephen
>
>
>

Re: Where should I start, if I want to build the SVN project?

[Stephen Connolly]

BTW, I am not implying that Saiho has emailed me personally asking more
questions, just that it was a posibility when I wrote the original reply

On 12 April 2010 14:38, Stephen Connolly wrote:

> Well fine then. what I meant to say is:
>
> "You have exhausted the amount of help you will get from me on this topic,
> so don't send me personal emails asking for more help because you will not
> get it"
>
> On too many occasions I reply to a post only to have the original
> questioner decide that I must therefore be the "expert" on the topic that I
> replied to... actually that is not the case, I gave you all the pointers I
> have at the moment, and emailing _just me_ with more questions will only
> delay you getting the answer, especially when Google searches can give
> better answers than me
>
> ;-)
>
> -Stephen
>
>
> On 12 April 2010 11:58, Justin Connell wrote:
>
>>  *Google is your friend for finding things
>>
>> *
>> There is no need for facetiousness..
>>
>>
>> Stephen Connolly wrote:
>>
>> On 12 April 2010 03:48, Saiho Yuen  wrote:
>>
>>>   HI,
>>>
>>> I wish to build a custom GUI for SVN with Java. And I wish to learn from
>>> the start, so I would like to learn how to build the SVN project form the
>>> source codes. So can someone please tell me where can I get the
>>> documentation? I'm working on Vista, should I use the MS Visual Studio or
>>> another compiler or do I need other softwares?
>>>
>>> thanks you very much
>>>
>>> Saiho
>>>
>>>
>> If you are writing the GUI in Java you might be better off using the
>> SVNKit libraries as that way you will not have to deal with JNI.
>>
>> Google is your friend for finding things
>>
>> -Stephen
>>
>>
>>
>

Re: Question about auto commit

[Stephen Connolly]

have you looked into svn:externals

On 19 April 2010 08:41,  wrote:

> hello
>
> I have a situation, where there are two(or more) projects with its trunks,
> and some modules in these trunks are the same:
>
> /project1
> /project1/trunk
> /project1/trunk/module_123
> /project1/trunk/module_1234
> /project1/trunk/module_12345
> /project1/trunk/module_4567
>
> /project2
> /project2/trunk
> /project2/trunk/module_23456
> /project2/trunk/module_1234
> /project2/trunk/module_789
> /project2/trunk/module_56789
>
> in above example, module_1234 is identical in both project.
> When I change something in /project1/trunk/module_1234 I have to change it
> also in /project2/trunk/module_1234 (because it has to be the same)
> If there is more than two project this operation will take some time.
>
>
> What is the best way to automate such case?
>
> - create some script on client side? (each developer would use such script)
> - create some script on server side? (hooks, no script would be needed on
> developer side, but could it be done using hooks???)
> how such hook (probably post-commit) would looks like?
> svn update project2
> svn merge -c $REV http://svn/project1/trunk/module_1234
> svn commit -m "" project2
>
> ???
>
> - any other?
>
>
> Best Regards
> Jacek
>
>
>

Re: Restoring corrupt revision

[Stephen Connolly]

The clean way would be to do a dump of your repo from after the dirty
revision.

Do a dump up to and including the dirty revision from your known good copy

do a load of the clean dump + the live dump

On 22 April 2010 08:30, vishwajeet singh  wrote:

>
>
> On Thu, Apr 22, 2010 at 12:49 PM, Cooke, Mark wrote:
>
>> >>
>> >> I have identified a single corrupt revision in the repository.
>> >>
>> >> Is restoring that  ** specific **  revision from a tape
>> >> backup a reasonable approach or is it a hack and could cause
>> >> further problems down the track.
>> >>
>> > I don't see any other option than this either, even if this
>> > is hack, I have done similar thing for one of our
>> > repositories  and haven't faced any problem in future, so
>> > even if this is hack I don't see any problem with the approach.
>> >
>> Out of interest, how can you restore a single revision into a repo?  I
>> am assuming reasonably clever use of dump and restore?  Including from a
>> recovered version of the repo on a spare svn server?  Or is there a
>> quicker/easier way?
>>
>>
>  There is quicker and wicked way to do it at least the way I did it, I am
> not sure if the approach was right or wrong but  this will only work if you
> have backup of repository  at some point which is not corrupted just go to
> the db directory  of repository copy that revision and past it in your
> corrupted repository but as I said this is hack and not a clean approach but
> worked for me, I am not recommending it to anyone to try it at your own
> risk, that was a last resort for me and worked.
>
> Regards,
>
> Vishwajeet Singh
> +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
> Twitter: http://twitter.com/vishwajeets | LinkedIn:
> http://www.linkedin.com/in/singhvishwajeet
>

Re: Two svn/apache servers accessing one database

[Stephen Connolly]

On 10 June 2010 06:34, Richard England  wrote:

>  On 06/08/2010 01:48 AM, Ulrich Eckhardt wrote:
>
> On Saturday 05 June 2010, Richard England wrote:
>
>
>  Are there any possible repercussions of having two server both running
> Apache/SVN (same version)  accessing the same database files?  This is
> using FSFS.
>
> Is this likely to cause data corruption or anything nasty?
>
>
>  You can easily have multiple concurrent accesses even without running two
> Apaches, e.g. concurrent file accesses by different users on the same
> machine, different svn+ssh sessions, multiple svnserve instances spawned by
> [x]inetd etc.
>
> In other words, it works.
>
> Uli
>
>
>
>
> Andy, the rationale is to allow a team to migrate from one server to
> another over time rather than forcing them to move their working copies
> before it makes sense in their development process.  They are aware they can
> use "svn switch --relocate" to update the working copes but this would make
> it a little more palatable for them.
>
> Than you Andy, and Uli.
>
> --
> --
> *~~R*
>


Why not just have the old server issue a 301/302 to the new server location
(I can never remember which is moved permanently)?

-Stephen

Re: How to automatically run some test when check-in

[Stephen Connolly]

On 12 June 2010 10:55, Kevin Wu  wrote:

> Thanks to those replied.
>
> I want to try svn hooks first.
>
>
You can use the svn hooks to trigger hudson or have hudson poll svn.

For maintenance, I recommend hudson polling svn rather than the svn hook
mechanism.

Just use Hudson you'll be set up in 30min as long as you have a machine with
Java 1.5+ on it to run Hudson (you don't need to be writing java software to
use Hudson)

-Stephen


> After reading the documentation, I still don't know how to get the filename
> and its path of the file being committed when the post-commit hook fires.
>
> The post-commit hook just has two arguments:
>
> 1. Repository path
> 2. Revision number created by the commit
>
>
>
> On Sat, Jun 12, 2010 at 12:07 PM, Les Mikesell wrote:
>
>> Kevin Wu wrote:
>>
>>> Hi,
>>>
>>> I am new to svn.
>>>
>>> I want that every time someone checks in his or her code, the sever can
>>> invoke some tests, which might run on another server.
>>>
>>> The svn sever only invokes the tests; it doesn't run them.
>>>
>>> Is svn capable of doing this?
>>>
>>
>> You might run some ssh command as a post-commit hook, but you would
>> probably be better off using something like hudson (http://hudson-ci.org/)
>> which can poll for changes and run jobs with a more complete cross-platform
>> framework.
>>
>> --
>>  Les Mikesell
>>   lesmikes...@gmail.com
>>
>
>
>
> --
> Best wishes,
> Kevin Wu
>

Re: What would be the best way to create "working repositories"?

[Stephen Connolly]

On 29 June 2010 13:54, Tom Malia  wrote:

>  I’m looking for an easy way to allow programmers on a large project to
> create something equivalent to a personal “branch” on the main project that
> they can check their “Work In Process” (WIP) in and out of while they
> actively develop a feature or enhancement over the period of several days to
> several months.  Then when they feel it’s ready they need to do the
> functionally equivalent to merging the branch back into trunk.
>
>
>
> It appears that all this would be pretty simple if they literally did just
> create a branch on the main project.  However, for a number of different
> reasons, I’d prefer that they could have a separate repository for their
> WIP.
>
> Would the number of reasons be:

1. You are a fool

;-)

>
>
> The scenario I’m thinking of is one in which there’s a main company that
> controls the project and tightly manages the Subversion Repo for it.  They
> are granting subcontractors rights to check-out parts of the project from
> the main repository but they only want to allow those subcontractors to
> “check in” product that is ready for at least Beta testing.  In the mean
> time, the subcontractors want to be able to check their WIP files in and out
> of a repository over the course of the days or weeks that they are working
> on it.
>
> Sounds like you would be better served with a distributed version control
system like GIT/Mercurial

Alternatively you could have the subcontractors work in GIT repos based off
the subversion repo.  When ready you just pull an update from the GIT repo
and then committ the changes to SVN.

There are even tools to help automate the process.

>
>
> One thought I had, that I’d like to know if there’s an easy way to do it or
> if I’m just heading down the completely wrong path.
>
>
>
> I’d like to be able to:
>
> 1)   “export” sections of the “main” repository
>
> 2)   Then add the directories that were just exported to a repository
> that would the “working repo”
>
> 3)   Check out the stuff just added to the “working repo” to a
> “working copy” (WC)
>
> 4)   Developer does their development in this WC, checking things into
> the “working repo” whenever they wish to make sure the have a snapshot or
> backup of their work
>
> 5)   When the developer feels they are ready to “merge” their work
> back in to the “main” repo they would do something like:
>
> a.   Check out the equivalent section of the “main” repo to a separate
> WC
>
> b.   Delete everything from that WC
>
> c.   Copy everything from the “WC” that came from their “Working repo”
> to the now “empty” WC from the main repo
>
> d.   Diff the current files in the “main” WC against the current
> version of the “main” repo and resolve conflicts
>
> e.   Check the WC from the “main” repo back into main
>
> f. Delete all WC folders from their local machine
>
> g.   Delete the entire “working repo”
>
>
>
> One big flaw I see in this is, I’m not sure how deletes would be tracked,
> though I’m sure there’s plenty of other problems with this that I haven’t
> thought of.  But then I’m guessing I’m not the first person to want to do
> something like this.
>

Loads of issues with resolving merge conflicts because you are throwing away
the change history, so there will effectively be no merge history

>
>
> A key aspect is, the end result HAS to be REALLY easy to teach people to do
> and I need it in a Windows environment.  Currently most of the developers
> are not interested in knowing any more about Subversion than what they know
> right now, which is, it acts “kind of like a network share”.
>
>
> If you have developers who don't care about version control then you have
worse problems.

> Thanks in advance,
>
> Tom Malia
>
> T&T Data Solutions L.L.C. 
>
>
>
>
>
-Stephen

Re: What would be the best way to create "working repositories"?

[Stephen Connolly]

On 29 June 2010 14:39, Tom Malia  wrote:

> Completely understood and agreed.
>
> As I said, I was setting the stage, not dictating the absolute.
>
> I understood and agreed with Stephen's core points.   I didn't find the
> approach to communicating those points particular efficient.
>

Only one comment was tongue-in-cheek and it even had a smiley

All the rest were IMHO direct and too the point. Applogies if my brevity
causes offence

-Stephen


> My goal with the "over taxed" developers is explicitly to reduce that load.
> I am not necessarily "over taxed" and if necessary I'm looking for ways
> that
> I can take on as much of the burden of learning and possibly doing the
> processes necessary and only have to push as little as possible of that
> burden to the developers.
>
> Tom Malia
> T&T Data Solutions L.L.C.
>
>
> -Original Message-
> From: Andy Levy [mailto:andy.l...@gmail.com]
> Sent: Tuesday, June 29, 2010 9:24 AM
> To: Tom Malia
> Cc: Stephen Connolly; users@subversion.apache.org
> Subject: Re: What would be the best way to create "working repositories"?
>
> On Tue, Jun 29, 2010 at 09:16, Tom Malia  wrote:
> > Stephen,
> >
> >
> >
> > I appreciate you taking the time to reply.  I know many of your comments
> are
> > tongue-in-cheek and I don’t take them too personally.  However, I don’t
> find
> > them terribly helpful either.  I wont waste anymore bandwidth here on
> that
> > aspect of your reply.
> >
> >
> >
> > I have no idea what GIT is.  If it’s another product that I would have to
> > dedicate more resources to learning myself and training the already over
> > taxed developers then I don’t think it’s a great idea for my situation.
>
> A 5-second Google search will inform you as to what git is.
>
> Stephen makes a valid point, though - if you & your developers are so
> "overtaxed" that proper source control is too much to handle (this
> includes your developers not understanding Subversion beyond what
> you've described), then you have worse problems than the one you've
> asked for help with here.
>
> In the end, I think you'll find you spend more time, money & effort
> doing it wrong than you will in training & staffing appropriately to
> do it right. Or, to paraphrase a sign seen around my office: If don't
> have time to do it right, when will you have time to do it twice?
>
>

Re: How to get the client hostname while user committing the code to the repository?

[Stephen Connolly]

Probably not available.

Keep in mind that depending on how a repo is set up people could be
accessing it via:

svn:
ssh+svn:
http:
https:

They kep point here is that ssh+svn will appear to subversion as a commit
from localhost (i.e. 127.0.0.1)

So it is likely that the commit scripts do not have the info passed through
because the info could well be useless... a.k.a. Design for lowest common
denominator

-Stephen

On 26 July 2010 10:57, Dharmaraj, Ramkumar  wrote:

>  Hi,
>
>
>
> I need your help.
>
>
>
> I need the client host information in either pre or post-commit trigger.
>
>
>
> Regards,
>
> Ram
>
>
>
> --
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmas...@nds.com and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes.
> To protect the environment please do not print this e-mail unless
> necessary.
>
> An NDS Group Limited company. www.nds.com
>

Re: Limit The size of Commit in SVN

[Stephen Connolly]

On 4 February 2014 10:45, Mehboob Ahmed  wrote:

> hey Johan,
>
> all i want is when my developer hit the commit button my script trigger the
> error if the commit size only commit size no repository size only that
> perticular commit size is greater than a GB.
>
> @echo off
> :: Stops commits that have size of greated than 1GB.
> @echo off
>
>
>
>
> set REPOS=%1
>
> set TXN=%2
>
> set MAX_BYTES= 1073741824
>
> svnlook changed -t %TXN% %REPOS%
>
> svnlook filesize -t %TXN% %REPOS% %changed%
>
> for /D /r %%G IN (%TXN%) DO (
>
> if "%G%" GEQ "%MAX_BYTES%" (goto :err) else exit 0  )
>
> :err
> echo Your commit has been blocked because your commit size is exceed. 1>&2
> echo Kindly Commit less than 1GB. 1>&2
> echo Thanks Regards 1>&2
> exit 1
>
>
You're still going to have the 1GB transferred to the server before the
script runs... unless I misunderstand... so what is the utility in such a
restriction? You won't be saving the server load or the client commit
time... the only thing you may catch is somebody committing very large
binary files to SVN... which probably suggests a different check anyway



> Please Guide will be very great full to you.
> Regards
> Mehboob Ahmed
>
>
>
> --
> View this message in context:
> http://subversion.1072662.n5.nabble.com/Limit-The-size-of-Commit-in-SVN-tp186696p186895.html
> Sent from the Subversion Users mailing list archive at Nabble.com.
>

Re: Limit The size of Commit in SVN

[Stephen Connolly]

Nope I cannot. I don't use windows, and I only use SVN for those projects I
work on that are still on SVN.

I think you are missing the point that *everyone* has been trying to get
you to see...

What is the benefit in stopping 1GB+ commits?

Either the developer is going to split the commit into two 0.9GB revisions
and commit the 1.8GB anyway... so not stopping the repository from becoming
bloated... or the developer will keep those files out of source control...
so defeating the whole point of source control.

I contend that the real issue here is that you don't want developers
committing large binary files. In which case the commit hook should look
for large binary files and reject commits including them.

If you are concerned with server load, a commit hook is too late... the
file has already landed on the server when the server side hooks are
running.

If you are concerned with large binary files in SVN, a different commit
hook is what you want, i.e. one that stops the large binary files... not
one that prevents what may be a legitimate commit.

Consider the case where there are video prompts associated with text
messages in a repository.  When committing a change to the text messages,
you should also commit the updated prompts (because it is a change that
should be part of the commit... having an incorrect video prompt for the
text message is a bug).

If I have to rework 20 of the messages as a result of a single refactoring
(introducing another screen, so all the messages now have to have "or via
the foo screen" appended... which requires a re-recording of all affected
messages by the talent), that could well mean committing the code for the
addition of the "foo" screen, with the message text changes and the updated
video files.

Putting a 1GB limit per revision will prevent me committing the change as a
single commit (which one can argue is the correct thing to do for this
single change).

TL;DR it sounds very much like you are solving the "wrong" problem... ask
yourself what is the real problem you want to solve and then solve that
problem instead.


On 4 February 2014 12:03, Mehboob Ahmed  wrote:

> hi Stephen
>
> i've shared the incmplete hook. if the commit size is larger than one gb
> than commit should cancel and prop up the echo msg... and let user commit
> less than 1GB data. can u provide me hook for windows for Tortoise SVN
>
>
>
> --
> View this message in context:
> http://subversion.1072662.n5.nabble.com/Limit-The-size-of-Commit-in-SVN-tp186696p186905.html
> Sent from the Subversion Users mailing list archive at Nabble.com.
>