[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: SVNROOT (again)

From: Srilakshmanan, Lakshman <lakshman.srilakshmanan_at_police.vic.gov.au>
Date: 2007-10-19 01:58:55 CEST

Hi Micah,

I share your pain. :)

I overcame this issue by providing my team with a browser to traverse
the SVN repository.
All they have to do is locate the project they need, copy the URL from
the browser and use it in their choice of client.

Thanks
Lakshman
-----Original Message-----
From: Micah Elliott [mailto:mde@micahelliott.com]
Sent: Friday, 19 October 2007 9:40 AM
To: users@subversion.tigris.org
Subject: SVNROOT (again)

Sorry to bring this up again; I think it's been a few years, and worth a
revisit. I found this old thread, which didn't seem to ever make it
anywhere:

    http://svn.haxx.se/dev/archive-2002-10/0164.shtml

Basically, it proposed to accept '//' as command substitution for svn
info's URL: parameter, truncated to its root. At least that's how I
read/expect it. Which basically is the same as CVSROOT. Sounds good to
me! Why wasn't this ever implemented?
Maybe my search just missed a definitive discussion?

I need some way to provide CVS's CVSROOT functionality to my Subversion
users. We'll Real Soon Now be converting from CVS to Subversion and it
appears that it will be *too hard* for common users to type URLs (which
would be *really* long in our case), and probably even too hard to use
environment variables like $REPOURL, in svn commands.

IOW, even "svn switch $REPOURL/branches/feature42" is too unwieldy.
Why? I have to play down to the most ignorant user's abilities. It's
apparently hard for users to remember an envar's name, or even how to
specify one! Also tough to conventionalize and enforce.

But we do have some environmental setup scripts happening before any
would-be svn usage. So I can do anything I want before-hand with the
environment, like

    SVNROOT="some://really/long/path/to/branches/".

Today they are able to do things like:

    cvswrapper checkout 6.0 # get the v6.0 branch

My goal is to not have to write an analogous 'svnwrapper', even if it's
just a small bash function. Though it's looking inevitable. The
acceptable svn anolog would be:

    svn checkout //6.0
    # or
    svn checkout //branches/6.0

Am I the only one in this predicament of having to enable Average Joe
Developer?

SVK has adopted and conventionalized the '//' syntax. Does that help to
justify Subversion's adoption? (I realize '//' is a synonym for '/' on
unix, but I don't find that a compelling reason not to use it.)

Another strength of SVK's // approach is that it enables a shell's
"command completion". So to get to my deeply nested branch at say
"some://really.long.root/branches/micah/features/fastfrob", I could just
type:

    svn sw //b<tab>/m<tab>/f<tab>/f<tab>

Granted, that introspection would be slower than with SVK, but still
doable.

-- 
                          _ _     ___
                          |V|icah |- lliott
                          " "     """
mde_at_MicahElliott.com            <><             http://MicahElliott.com
PGP: 0x7C07CBF0          ICQ: 369060435      Linux/Ubuntu: 417195/12440
HackerKey: v4sw6YUPCJhw5ln5pr7OPck2ma9u8Lw3m5l6Ui2e7t3b8LDMOen6a3XsMRr5
================================================================================================
EMAIL DISCLAIMER
This email and any attachments are confidential. They may also be subject to copyright.
If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email. 
You must not read, use, copy, retain, forward or disclose this email or any attachment.
We do not accept any liability arising from or in connection with unauthorised use or disclosure 
of the information contained in this email or any attachment.
We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 19 01:59:01 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.