Peter Davis <peter@pdavis.cx> writes:
> $ svn co http://username:password@server/repos/
Isn't this an IE or Netscape-only syntax? I can't remember.
> $ svn propedit svn:externals .
> [in emacs:]
> module http://username:password@my-other-server/repos/blah
> $ svn ci -m ""
>
> [at this point, I couldn't just 'svn up' to get it to try and check out the
> modules, maybe that is a whole other bug]
Actually, this is a whole psuedo-maybe-bug I'd had made a mental note
to discuss with Karl, but forgot.
I thought one of the "cool" things about svn's module implementation
was that *unlike* cvs, a subversion module was able to change over
time. In cvs, if you check out a module, the working copy retains no
memory of its module-ness. If somebody else changes the definition of
the module, the cvs working copy never finds out. In an svn working
copy, though, if somebody changes the 'svn:externals' property, then
'svn up' should cause things to shift and change in your working copy.
Here's what I've noticed:
1. as Peter points out, 'svn up' right after setting the property
does nothing at all... the externals aren't checked out.
2. If I check out a module, I end up with a few 'external'
subdirectories. I'm aware that they aren't directly linked with
the root working copy. But still, when I run 'svn up' at the top
of my working copy, the update *never* happens in the external
subdirs. Your first response might be, "yes, well, the subdirs
aren't linked, so the update never recurses in there." But this
seems like a silly cop-out to me; why aren't we just running a
sequence of updates? It's so easy for 'svn up' to notice the
svn:externals property when it first starts, and have it queue up
a separate update for each external. And in my mind, this is how
a "working copy that's aware it's a module" should behave.
Maybe I should file an "incomplete feature" issue, assuming others
agree?
> I ask that you consider using the http://username:password@server format
> universally, unless there is another consistant approach available.
At a minimum, maybe the value of each external can be a string that
contains a URL and any number of switches... weren't we talking about
that idea?
subdir URL -r42
subdir2 URL --username foo --password -bar
?
> While on the discussion of authentication, and in a similar vein,
> the way auth info is stored in .svn doesn't make sense to me. I see
> an auth/ directory, with files 'username' and 'password'. Then I
> also see:
>
> <entry
> committed-rev="1"
> name="svn:this_dir"
> committed-date="2002-07-14T10:44:21.733385Z"
> url="http://username@server/repos/path..."
> last-author="username"
> kind="dir"
> revision="N"/>
These are totally unrelated bits of information. The stuff in the
.svn/auth/ area is a cached password that is used to respond to http
challenges.
The 'last-author' field in the entry is grouped with the
'committed-rev' and 'committed-date' field. Together, these three
bits describe the last revision in which the item changed, along with
the datestamp and author attached to that particular revision. This
informaton is used to expand keywords, and shows up in 'svn status -v'
as well.
I don't how you got 'username' into that 'last-author' attribute
there... is that indeed the name of the user that created revision 1?
If you 'svnadmin lsrevs /path/to/repos', does it say that? Or just
run 'svn log'...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 22 03:25:42 2002