svn - one realmstring and multiple usernames

[Jim Thompson]

Greetings!

There may be only one answer, but I'll describe my challenge in case someone 
has a better alternative.

I want to run a script (e.g., from cron and/or launched by a CI tool like 
Hudson) which runs some svn commands.  The tricky part is that the script may 
run svn commands using two repositories.  In my case, the username (and 
password) will be different in the two repos, but they have the same 
realmstring.

Here are examples of what I see in ~trantest/.subversion/auth/svn.simple/xxx

Either:
username
V 26
role_StudentAdmin_trantest

Or:
username
V 30
role_StudentAdmin-cfg_trantest

The trick is that the value of svn:realmstring remains the same... So whichever 
repo I last accessed (via a command line like: svn ls https://... --username 
 --password ) has those credentials overwrite the contents of the file 
(~trantest/.subversion/auth/svn.simple/xxx)

I see in the book:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache

"Credentials are cached in individual files; if you look inside each file, you 
will see keys and values. The svn:realmstringkey describes the particular 
server realm that the file is associated with"

It seems like we need a different realmstring available for one of the repos, 
in order to get two files generated and saved in 
~trantest/.subversion/auth/svn.simple

I'm not seeing another approach that will let my script access both repos, 
unless I change the script to provide --username and --password for each call 
(very nasty).  Any other ideas?

Thanks,
Jim

Re: Help

[Jim Thompson]

On Apr 19, 2010, at 5:50 PM, Ryan Schmidt wrote:

> 
> On Apr 19, 2010, at 17:39, Ryan Schmidt wrote:
> 
>> On Apr 19, 2010, at 17:04, Omar Ousmane Kadry wrote:
>> 
>>> Not sure if it is the right place for this but I’m looking for a way to 
>>> imitate the cvs behavior when checking out folders.
>>> In cvs:
>>>   cvs co mod1/dir1/dir2/file2
>>>   will result in having:
>>>   mod1/dir1/dir2/file2
>>> 
>>> How can I obtain this hierarchical checkout with SVN?
>> 
>> There isn't anything built into Subversion to do that. You'll have to make 
>> the directories yourself, for example using "mkdir -p".
> 

Maybe I misunderstood the question, but this works for me (with an added 
parameter, the directories are created by checkout)...

svn co https://.../example1/trunk/svn-admin/bin example1/trunk/svn-admin/bin


> Here's a quick unix script "svnco" I wrote which you could use instead of 
> "svn co" to do this. There's no error checking, no handling of special 
> characters (i.e. those that would be percent-encoded in URLs), and maybe 
> other issues, but it shows how it can be done.
> 
> 
> $ cat /path/to/svnco
> #!/bin/bash
> 
> URL="$1"
> 
> MKDIR=mkdir
> SED=sed
> SVN=svn
> 
> REPO_ROOT=$($SVN info "$URL" | $SED -n "s|^Repository Root: ||p")
> PATH_IN_REPO=$(echo "$URL" | $SED "s|^$REPO_ROOT/||")
> $MKDIR -p "$PATH_IN_REPO"
> $SVN co "$URL" "$PATH_IN_REPO"
> 
> 
> $ mkdir test
> $ cd test
> $ /path/to/svnco 
> http://svn.macosforge.org/repository/macports/trunk/dports/devel/subversion
> Atrunk/dports/devel/subversion/files
> Atrunk/dports/devel/subversion/files/patch-path.c.diff
> Atrunk/dports/devel/subversion/files/patch-Makefile.in.diff
> Atrunk/dports/devel/subversion/Portfile
> Checked out revision 66676.
> $ find .
> .
> ./trunk
> ./trunk/dports
> ./trunk/dports/devel
> ./trunk/dports/devel/subversion
> ./trunk/dports/devel/subversion/.svn
> ./trunk/dports/devel/subversion/.svn/all-wcprops
> ./trunk/dports/devel/subversion/.svn/entries
> ./trunk/dports/devel/subversion/.svn/prop-base
> ./trunk/dports/devel/subversion/.svn/prop-base/Portfile.svn-base
> ./trunk/dports/devel/subversion/.svn/props
> ./trunk/dports/devel/subversion/.svn/text-base
> ./trunk/dports/devel/subversion/.svn/text-base/Portfile.svn-base
> ./trunk/dports/devel/subversion/.svn/tmp
> ./trunk/dports/devel/subversion/.svn/tmp/prop-base
> ./trunk/dports/devel/subversion/.svn/tmp/props
> ./trunk/dports/devel/subversion/.svn/tmp/text-base
> ./trunk/dports/devel/subversion/files
> ./trunk/dports/devel/subversion/files/.svn
> ./trunk/dports/devel/subversion/files/.svn/all-wcprops
> ./trunk/dports/devel/subversion/files/.svn/entries
> ./trunk/dports/devel/subversion/files/.svn/prop-base
> ./trunk/dports/devel/subversion/files/.svn/props
> ./trunk/dports/devel/subversion/files/.svn/text-base
> ./trunk/dports/devel/subversion/files/.svn/text-base/patch-Makefile.in.diff.svn-base
> ./trunk/dports/devel/subversion/files/.svn/text-base/patch-path.c.diff.svn-base
> ./trunk/dports/devel/subversion/files/.svn/tmp
> ./trunk/dports/devel/subversion/files/.svn/tmp/prop-base
> ./trunk/dports/devel/subversion/files/.svn/tmp/props
> ./trunk/dports/devel/subversion/files/.svn/tmp/text-base
> ./trunk/dports/devel/subversion/files/patch-Makefile.in.diff
> ./trunk/dports/devel/subversion/files/patch-path.c.diff
> ./trunk/dports/devel/subversion/Portfile
> $
> 
> 
> 
> 
> 

Re: Hook to check for a presence of file before committing

[Jim Thompson]

SVN has a pristine copy of the checked-out files along with the working copy.  
When you issue a commit, SVN compares the pristine and the local files and 
_only_ sends the diffs.  So the presence of any file doesn't automatically mean 
that it will be visible in the commit _unless_ it changes every time.

Hope this helps.

Cheers,
Jim

On Aug 31, 2010, at 11:22 AM, Tech Geek wrote:

> >You want to enforce that the developer cannot commit unless they have this 
> >project.xml in >their working copy, though it will never be sent to the 
> >repository.
> That's not true. The project.xml (or whatever file that particular file is) 
> should also be a part of commit.
> 
> I will again repeat my question again since there is so much confusion:
> 
> Can we have a pre-commit (preferred) or post-commit server hook that can 
> check for the presence of a particular file (say project.xml) when the users 
> send their working copy to the server to commit? If the file is present 
> accept the commit (along with that file) else reject the commit.
> 
> I would prefer not to implement this on client side.
> 
> I never thought this would be so complicated.