You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Tony Hoyle <tm...@nodomain.org> on 2003/07/16 10:32:56 UTC
Some questions...
Forgive an old cvs veteran but there's a couple of things I can't work
out how to do with subversion...
1. Is the hooks directory versioned in any way? In our setup nobody
gets physical access to the repository, but multiple people may need to
add things for their particular modules... with cvs you just checkout
the cvsroot and edit it - any equivalent?
2. 'svn ls' seems to require a checked out sandbox, which to me defeats
the point, or am I using it wrong?
3. How can I restrict commit/tag access to various bits of the
repository for different users?
4. How do I put a watch on a file?
5. How do I lock a binary file? (locks are really needed for binaries
otherwise stuff gets lost)
6. How do you handle UCS-2 files? We have large numbers of these...
Tony
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
kfogel@collab.net writes:
> > 5. How do I lock a binary file? (locks are really needed for binaries
> > otherwise stuff gets lost)
>
> I don't understand the parenthetical claim, but in any case,
> Subversion does not support locking right now. It may someday, but
> that's post-1.0.
Regarding Tony's parentheses:
In Subversion, if your locally-modified binary file needs to be
patched during "svn update", the svn client will simply produce three
full files in your working copy. It won't attempt to do a contextual
merge.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> This subject has never been brought up before; I wasn't aware it was
> Subversion's responsibility to deal with every possible unicode
> encoding. You make a good point, though. Subversion definitely
> *could* grow a new "svn:encoding" property, convert encodings to UTF8
> for mergeability, and convert back. It would be a bit of work to
> write this feature, but nothing horrible.
>
> Still, it still feels like a post-1.0 change to me. Not high priority
> at the moment.
I agree. There's nothing controversial about supporting all unicode
encodings, but it's just a matter of prioritizing. IMHO, we should
tackle this after 1.0, and tell people to use UTF-8 until then.
Obviously not ideal, but then, life *is* pain, as Westley said in The
Princess Bride.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
Jack Repenning <jr...@collab.net> writes:
> So, for example, CVS update consists of the client sending a list of
> what it has, whereas SVN update consists of the client sending what it
> needs (unless I got that backwards, but either way the example works).
> The one list is essentially the complement of the other.
That's almost a correct analysis.
* cvs update, as you say, sends an exhaustive list of what it has:
every single file and it's version-number.
* svn updates normally say "I have revision N of some big tree, with
the following exceptions: {this subtree is a revision X, and this
file over here is at rev Y, ...}". It's very compressed, because
client and server have a shared understanding that "revision N" of
some directory implies a very specific tree.
* recently, svn updates acquired the ability to fall back into "cvs
mode". The svn client can now say, "I have revision N of a
directory, but I think it's incomplete, so here's an exhaustive
list of the immediate children."
This last mode is probably what the 'translator' module would use.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
Jack Repenning wrote:
> So, for example, CVS update consists of the client sending a list of
> what it has, whereas SVN update consists of the client sending what it
> needs (unless I got that backwards, but either way the example works).
> The one list is essentially the complement of the other. So this
> intermediary would intuit "update," respond "yeah, yeah, yeah"
> endlessly, meanwhile launching an SVN update (and the standard SVN code
> would send along the list of what's needed).
Basically, yes. You'd end up caching information, since a live
translation would be overcomplex (it's probably enough to cache the
metadata).
I might start by putting the bridge capability into cvsnt (since most of
the hard work is done & I know the code), then writing a standalone one
later. Proof of concept, I guess.
Tony
Re: Some questions...
Posted by Jack Repenning <jr...@collab.net>.
At 10:22 PM +0100 7/16/03, Tony Hoyle wrote:
>Remember I'm not trying to make an SV client talk to a CVS server
>(that'd probably be impractical) but the other way around - you can
>dump a lot of junk at the CVS client and it'll faithfully send it
>back during an update/commit without looking too hard at it. It's
>not a direct 1:1 translation, and I doubt it's a small project (I
>reckon a couple of months to get it usable) but it's worth doing.
I guess your idea here is: a process (or COM server, perhaps, some
entity), running on the client machine
* that receives the CVS protocol messages
* intuits the underlying meaning
* performs the corresponding svn operations
* including whatever annotations, expansions, or ellipses might be
necessary because of the differences
* receives the SVN responses
* intuits their underlying meaning
* expresses that as responses to the CVS protocols
So, for example, CVS update consists of the client sending a list of
what it has, whereas SVN update consists of the client sending what
it needs (unless I got that backwards, but either way the example
works). The one list is essentially the complement of the other. So
this intermediary would intuit "update," respond "yeah, yeah, yeah"
endlessly, meanwhile launching an SVN update (and the standard SVN
code would send along the list of what's needed).
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
Ben Collins-Sussman wrote:
> Let me warn you: this is not a problem of translating syntaxes,
> it's a problem of translating semantics. For example:
>
> * for an update, the svn server expects the working copy to report
> version information about *directories*, not just files. one
> system versions trees, the other just versions files.
No biggie, just send to extra metadata to the client.... I even had
cvsnt versioning directories at one point but decided it wasn't worth
the effort. If you send a version number in a 'D/...' entries line it
does get preserved (altough IIRC getting the client to send it back has
pitfalls, which I'll have to look at the commit logs to find out how I
got around it).
> * how about branches and tags? one system treats them as labels on
> file-versions, and another treats them as whole directories.
That's just trivial rewriting. They're just different expressions of
the same thing..
That hard stuff is for example making a reasonable representation of
'cvs status' or 'cvs log'... tags and metadata are relatively trivial
by comparison.
Remember I'm not trying to make an SV client talk to a CVS server
(that'd probably be impractical) but the other way around - you can dump
a lot of junk at the CVS client and it'll faithfully send it back during
an update/commit without looking too hard at it. It's not a direct 1:1
translation, and I doubt it's a small project (I reckon a couple of
months to get it usable) but it's worth doing.
Tony
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
Tony Hoyle <tm...@nodomain.org> writes:
> Ben Collins-Sussman wrote:
> This idea just isn't possible. CVS and SVN are just so
> > fundamentally different under the hood (despite UI similarities),
> > there is *no* way a subversion server can ever "translate" cvs
> > protocol into subversion semantics. That's my feeling.
>
> It's probably do-able... yes, they're different, and the translation
> would probably have to have a caching element (for example CVS tends
> to send whole files rather than deltas from the client), but the CVS
> client is actually rather a dumb beast, and the obvious differences
> like version numbers can be faked anyway (just stick '1.' in the front
> is probably enough... there's little or no parsing of it
> anyway.. something a bit smarter would be nice but I'd have to look
> closely at it so see whether it's worth it).
The fact that you said that ("just stick 1. in front of the version
numbers") tells me how much pain you're about to experience. It's
clear that you don't know much about Subversion yet. :-)
Let me warn you: this is not a problem of translating syntaxes,
it's a problem of translating semantics. For example:
* for an update, the svn server expects the working copy to report
version information about *directories*, not just files. one
system versions trees, the other just versions files.
* how about branches and tags? one system treats them as labels on
file-versions, and another treats them as whole directories.
The list goes on and on. Go ahead and try it. I'll keep my mouth
shut.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
Ben Collins-Sussman wrote:
This idea just isn't possible. CVS and SVN are just so
> fundamentally different under the hood (despite UI similarities),
> there is *no* way a subversion server can ever "translate" cvs
> protocol into subversion semantics. That's my feeling.
It's probably do-able... yes, they're different, and the translation
would probably have to have a caching element (for example CVS tends to
send whole files rather than deltas from the client), but the CVS client
is actually rather a dumb beast, and the obvious differences like
version numbers can be faked anyway (just stick '1.' in the front is
probably enough... there's little or no parsing of it anyway.. something
a bit smarter would be nice but I'd have to look closely at it so see
whether it's worth it).
Client->Server CVS just sends a bunch of arguments and the command,
followed (optionally) by the files and/or entry daya... then you just
have to work out the equivalent SV command and pass that onto the SV
server. Server->Client is even simpler... the CVS client just does what
it's told by the server - it doesn't actually implement anything itself
(this is why for example with all the changes I made to CVS I can only
think of a couple of cases where the client had to change).
It doesn't have to be perfect, just enough to work with the existing
CVS-aware tools (at least those that don't try to parse the response
text... I doubt there's a way it would ever work with Eclipse, for
example).
Tony
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
Tony Hoyle <tm...@nodomain.org> writes:
> If I can get enough features in I just have to write the CVS
> Client/server protocol as a plugin to subversion [...]
I'm feeling wet-raggy today:
This idea just isn't possible. CVS and SVN are just so
fundamentally different under the hood (despite UI similarities),
there is *no* way a subversion server can ever "translate" cvs
protocol into subversion semantics. That's my feeling.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
kfogel@collab.net wrote:
> Tony Hoyle <tm...@nodomain.org> writes:
>
>>I need to make at least my copy of subversion do everything cvs does
>>for me at the moment, before I'd consider changing. A lot of the
>>stuff can either be done with scripts or outside the main tree, but
>>some of it just needs a code, unfortunately.
>
>
> CVS does this for you???
>
Well, CVSNT does, but it's still mostly CVS :)
A lot of the stuff that was added I put in because I or my employer
wanted it, so I can't really switch to a system that doesn't support it.
If I can get enough features in I just have to write the CVS
Client/server protocol as a plugin to subversion, and I can switch the
server without anyone even noticing (in theory...). It also means I can
put CVSNT it maintenence and take a break from it (3.5 years on the same
project gets wearing).
Tony
Re: Some questions...
Posted by kf...@collab.net.
Tony Hoyle <tm...@nodomain.org> writes:
> I need to make at least my copy of subversion do everything cvs does
> for me at the moment, before I'd consider changing. A lot of the
> stuff can either be done with scripts or outside the main tree, but
> some of it just needs a code, unfortunately.
CVS does this for you???
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
Ben Collins-Sussman wrote:
> Wait, hold on. Nothing is preventing you from using unicode .java
> files. Your problem is that you're using an unmergeable encoding,
> like UCS2, or whatever. Why not just use UTF8 source files instead?
> Then you get normal, mergeable text.
Unfortunately the in-house tools are all native Unicode, and I can't
change that.
There's no reason why UCS2 can't be mergeable... cvsnt does this already
in exactly the way I describe - it works well (never had any negative
feedback on it, anyway).
> This subject has never been brought up before; I wasn't aware it was
> Subversion's responsibility to deal with every possible unicode
> encoding. You make a good point, though. Subversion definitely
There's only a few, really, from the point of view of source control.
Text - basically anything you can use strlen() on or printf() etc. This
includes pure ANSI and UTF8... MBCS fits this, too.
UCS2-LE
UCS2-BE -- UTF16 is just an instance of UCS2 for the purposes of storage.
UCS4-LE
UCS4-BE
UCS4 is less useful (I'm currently unaware of any system that actually
uses it).
UCS2/UTF16 is extremely common in asia, where they're pretty much forced
to use it or be stuck in codepage hell.
UTF8 is the lowest common denominator for all the UCS/UTF encodings...
you can go back and forth without losing any data.
> *could* grow a new "svn:encoding" property, convert encodings to UTF8
> for mergeability, and convert back. It would be a bit of work to
> write this feature, but nothing horrible.
It's probably relatively trivial.. there's already a lot of translating
going on.. cr/lf, stripping keywords, etc. It's just an extra call.
> Still, it still feels like a post-1.0 change to me. Not high priority
> at the moment.
I'd write it myself, anyway, since it's a priority for me :)
I need to make at least my copy of subversion do everything cvs does for
me at the moment, before I'd consider changing. A lot of the stuff can
either be done with scripts or outside the main tree, but some of it
just needs a code, unfortunately.
Mergepoint handling is my next big beef, but you guys already plan to
add that so hopefully it won't be long (we maintain two branches and
merge daily between them... without mergepoints that wouldn't be practical).
Speculative branching I could live without - it's surprisingly useful
but I suspect it's not going to be compatible with the way SV handles
its repositories.
Tony
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
Tony Hoyle <tm...@nodomain.org> writes:
> There really isn't any other way to do it. Unicode support is
> essential in a version control system these days... certainly I
> couldn't do without it... our java team would go ballistic if they
> couldn't merge unicode.
Wait, hold on. Nothing is preventing you from using unicode .java
files. Your problem is that you're using an unmergeable encoding,
like UCS2, or whatever. Why not just use UTF8 source files instead?
Then you get normal, mergeable text.
This subject has never been brought up before; I wasn't aware it was
Subversion's responsibility to deal with every possible unicode
encoding. You make a good point, though. Subversion definitely
*could* grow a new "svn:encoding" property, convert encodings to UTF8
for mergeability, and convert back. It would be a bit of work to
write this feature, but nothing horrible.
Still, it still feels like a post-1.0 change to me. Not high priority
at the moment.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
Ben Collins-Sussman wrote:
> What? You're advocating munging the *entire* contents of a file back
> and forth? I don't understand why you want to do this.
>
What do you think lf translation does?
There really isn't any other way to do it. Unicode support is essential
in a version control system these days... certainly I couldn't do
without it... our java team would go ballistic if they couldn't merge
unicode.
> Either the contents of a file can be contextually merged, or they
> can't. *You* decide that, mark the file appopriately with svn
> metadata, and let the svn client either do it or not.
You can't just mark a unicode file as 'mergeable' and expect it to work.
Quite apart from the NULL bytes everywhere, there are LFs in the
middle of lines, and the ones at the end need expanding to
CR/NULL/LF/NULL. Also keyword substitution needs to work with it.
If you convert to UTF8 none of the underlying code has to change... UTF8
has the nice property that you can treat it as ANSI text for the most part.
Hell, if Unicode is so controversial I'm not even going to *start* with
mergepoint processing and speculative branching.
Tony
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
Tony Hoyle <tm...@nodomain.org> writes:
> Ben Collins-Sussman wrote:
> > The Subversion *client* (libsvn_wc) looks at metadata attached to
> > files in the working copy, and distingusishes between text and
> > binary files. Text files are considered "okay" for contextual
> > merging (during an update), eol-translation, and
> > keyword-expansion. Binary files aren't eligible for these things.
>
> We're just wildly agreeing here... It would be silly if the server
> cared about text/binary (CVS does it this way too although its sucky
> diffing algorythm tends hide the fact). The client, though, is
> responsible for turning the user file into something the protocol
> understands... Since UCS2 == Text then it should be the clients'
> responsibility to then encode this in UTF8 for transmisison/storage,
> and back again on an update, which is similar to eol-translation (but
> with more impact on the filesize)... With that you get keyword
> expansion and diffing for free.
What? You're advocating munging the *entire* contents of a file back
and forth? I don't understand why you want to do this.
Either the contents of a file can be contextually merged, or they
can't. *You* decide that, mark the file appopriately with svn
metadata, and let the svn client either do it or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
Ben Collins-Sussman wrote:
> The Subversion *client* (libsvn_wc) looks at metadata attached to
> files in the working copy, and distingusishes between text and
> binary files. Text files are considered "okay" for contextual
> merging (during an update), eol-translation, and
> keyword-expansion. Binary files aren't eligible for these things.
We're just wildly agreeing here... It would be silly if the server cared
about text/binary (CVS does it this way too although its sucky diffing
algorythm tends hide the fact). The client, though, is responsible for
turning the user file into something the protocol understands... Since
UCS2 == Text then it should be the clients' responsibility to then
encode this in UTF8 for transmisison/storage, and back again on an
update, which is similar to eol-translation (but with more impact on the
filesize)... With that you get keyword expansion and diffing for free.
Like I said, it should be relatively trivial to come up with a patch
that does it... once I can get the damned thing to compile :) Maybe
I'll give up trying to compile it on Win32 and code on Linux for a change...
Tony
Re: Some questions...
Posted by Ben Collins-Sussman <su...@collab.net>.
Tony Hoyle <tm...@nodomain.org> writes:
> kfogel@collab.net wrote:
>
> > If you're using ra_svn (the svnserve daemon & friends), I'm not sure
> > such a feature is implemented yet.
> >
> Ahh OK. I'd rather hoped that remote users could set ACLs on branches
> to lock them down (code freeze etc.)
>
> >>6. How do you handle UCS-2 files? We have large numbers of these...
> > Like any other file (we don't distinguish between text and binary,
> > though you might want to avoid setting the svn:keywords or svn:eol
> > property on those files!).
>
> So you don't convert to UTF8 and back... hmm.. might not be so useful
> since if you're treating the unicode files as binary they won't merge
> properly :(
Let's clarify some stuff here:
* file names
Subversion treats all file names (and paths) as UTF8 internally.
That means incoming paths get converted from native locale to
UTF8, and paths coming out of the repository get converted from
UTF8 to native locale.
* file contents
The Subversion repository and network layers treats all file data
as bytestrings... there's no notion of 'text' or 'binary' type.
The Subversion *client* (libsvn_wc) looks at metadata attached to
files in the working copy, and distingusishes between text and
binary files. Text files are considered "okay" for contextual
merging (during an update), eol-translation, and
keyword-expansion. Binary files aren't eligible for these things.
Does this make more sense, Tony?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Tony Hoyle <tm...@nodomain.org>.
kfogel@collab.net wrote:
> If you're using ra_svn (the svnserve daemon & friends), I'm not sure
> such a feature is implemented yet.
>
Ahh OK. I'd rather hoped that remote users could set ACLs on branches
to lock them down (code freeze etc.)
>>6. How do you handle UCS-2 files? We have large numbers of these...
>
>
> Like any other file (we don't distinguish between text and binary,
> though you might want to avoid setting the svn:keywords or svn:eol
> property on those files!).
So you don't convert to UTF8 and back... hmm.. might not be so useful
since if you're treating the unicode files as binary they won't merge
properly :( Plus there's the keyword issue. I might look at
implementing this (it's very similar to cr/lf conversion really... if
you're doing that then the code to convert should be relatively trivial
[especially since I have a chunk of code I already use in cvsnt that
does exactly that...])
Watches would be nice - I can sort of imagine how to do them using
scripts and coercing the property system...
Tony
Re: Some questions...
Posted by kf...@collab.net.
Michael Wood <mw...@its.uct.ac.za> writes:
> > With Apache conf directives, if you're using ra_svn (i.e., WebDAV) to
>
> s/ra_svn/ra_dav/
Thanks for catching that braino, Michael.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Wed, Jul 16, 2003 at 09:47:29AM -0500, kfogel@collab.net wrote:
> Tony Hoyle <tm...@nodomain.org> writes:
[snip]
> > 3. How can I restrict commit/tag access to various bits of the
> > repository for different users?
>
> With Apache conf directives, if you're using ra_svn (i.e., WebDAV) to
s/ra_svn/ra_dav/
> access your repository. Or you can use mod_authz_svn.
>
> If you're using ra_svn (the svnserve daemon & friends), I'm not sure
> such a feature is implemented yet.
[snip]
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some questions...
Posted by kf...@collab.net.
Tony Hoyle <tm...@nodomain.org> writes:
> 1. Is the hooks directory versioned in any way? In our setup nobody
> gets physical access to the repository, but multiple people may need
> to add things for their particular modules... with cvs you just
> checkout the cvsroot and edit it - any equivalent?
It's not versioned by default, but you certainly *could* put it under
revision control, like any other directory.
> 2. 'svn ls' seems to require a checked out sandbox, which to me
> defeats the point, or am I using it wrong?
Have you tried invoking it on a URL?
> 3. How can I restrict commit/tag access to various bits of the
> repository for different users?
With Apache conf directives, if you're using ra_svn (i.e., WebDAV) to
access your repository. Or you can use mod_authz_svn.
If you're using ra_svn (the svnserve daemon & friends), I'm not sure
such a feature is implemented yet.
> 4. How do I put a watch on a file?
You use CVS :-).
> 5. How do I lock a binary file? (locks are really needed for binaries
> otherwise stuff gets lost)
I don't understand the parenthetical claim, but in any case,
Subversion does not support locking right now. It may someday, but
that's post-1.0.
> 6. How do you handle UCS-2 files? We have large numbers of these...
Like any other file (we don't distinguish between text and binary,
though you might want to avoid setting the svn:keywords or svn:eol
property on those files!).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org