On 12/31/2011 09:21 PM, Daniel Shahaf wrote:
Mark Mielke wrote on Sat, Dec 31, 2011 at 01:00:12 -0500:
On 12/30/2011 09:35 PM, Daniel Shahaf wrote:
AuthLDAPRemoteUserAttribute cn
Then you can do
% svn commit --username "Daniel Shahaf"
and the logs will show
-
Mark Mielke wrote on Sat, Dec 31, 2011 at 01:00:12 -0500:
> On 12/30/2011 09:35 PM, Daniel Shahaf wrote:
> >Mark Mielke wrote on Fri, Dec 30, 2011 at 20:22:50 -0500:
> >
> >>I think you are not understanding my concern. If svn:author is only
> >>ever displayed to the user - then "authenticated user
It is also worth pointing out that your response, Stefan, is very will
written and reasonable and I'm putting it on my "to think about" pile.
Thank you.
On 12/31/2011 07:10 AM, Stefan Sperling wrote:
To fix your svn:author problem, you or someone else in this community
could try to come up wit
Hi Stefan:
You are correct. I've let my frustration get to me ... after years and
years of waiting and trying to contribute. I agree that the route
forward you describe is the best approach to getting something achieved.
However, I do think it is worth pointing out - very briefly and with
pu
On Fri, Dec 30, 2011 at 08:22:50PM -0500, Mark Mielke wrote:
> In any case - this is just yet another example of how Subversion
> really doesn't scale. That it still can't properly merge across
> branches or renames is much more important...
Mark, are you trying to make a useful contribution here
On 12/30/2011 09:35 PM, Daniel Shahaf wrote:
Mark Mielke wrote on Fri, Dec 30, 2011 at 20:22:50 -0500:
I think you are not understanding my concern. If svn:author is only
ever displayed to the user - then "authenticated username" may not
be a desirable form to use. For teams of 10 people, sure
Mark Mielke wrote on Fri, Dec 30, 2011 at 20:22:50 -0500:
> On 12/30/2011 02:36 PM, Daniel Shahaf wrote:
> >Mark Mielke wrote on Fri, Dec 30, 2011 at 14:24:25 -0500:
> >
> >>With the caveat being that tools that assume that svn:author was set by
> >>the Subversion API may no longer recognize the au
On 12/30/2011 02:36 PM, Daniel Shahaf wrote:
Mark Mielke wrote on Fri, Dec 30, 2011 at 14:24:25 -0500:
With the caveat being that tools that assume that svn:author was set by
the Subversion API may no longer recognize the author...
"by the Subversion API" isn't the right phrase, but anyway: by
Mark Mielke wrote on Fri, Dec 30, 2011 at 14:24:25 -0500:
> On 12/29/2011 11:09 PM, Daniel Shahaf wrote:
>> Steinar Bang wrote on Thu, Dec 29, 2011 at 22:55:09 +0100:
>>> Couldn't you just store this information as custom properties? Even
>>> though svn isn't able to use it, at least the informati
On 12/29/2011 11:09 PM, Daniel Shahaf wrote:
Steinar Bang wrote on Thu, Dec 29, 2011 at 22:55:09 +0100:
Couldn't you just store this information as custom properties? Even
though svn isn't able to use it, at least the information would be
preserved...?
Re "throw away the domains": svn:author
Steinar Bang wrote on Thu, Dec 29, 2011 at 22:55:09 +0100:
> > "Eric S. Raymond" :
>
> > On the other hand, when you *start* in gitspace, mapping back down to
> > the set of abstractions svn can handle is really lossy. You have to
> > throw away the domains on committer names, all the author
> "Eric S. Raymond" :
> On the other hand, when you *start* in gitspace, mapping back down to
> the set of abstractions svn can handle is really lossy. You have to
> throw away the domains on committer names, all the author fields, real
> (annotated) tags, and branch merges.
Couldn't you jus
On 12/14/2011 09:47 AM, Eric S. Raymond wrote:
> Heh. Just to add to the confusion, Daniel says that what I'm calling a
> "flow" is elswehere called a "node" and that what I'm calling a "node"
> is elsewhere called a "node-revision".
>
> I'm not sure how I want to deal with this in the 0.3 draf
C. Michael Pilato :
> On 12/14/2011 07:11 AM, Eric S. Raymond wrote:
> > Which brings up a question: should a delete on a non-empty directory succeed
> > or fail?
>
> Succeed.
Thank you, that will go into the 0.3 draft.
> > IMO, part of the reason this stuff is confusing is that your
> > termin
On 12/14/2011 07:11 AM, Eric S. Raymond wrote:
> Which brings up a question: should a delete on a non-empty directory succeed
> or fail?
Succeed.
> IMO, part of the reason this stuff is confusing is that your
> terminology is inadequate; see previous note to Daniel Shahaf. I get
> what you mean b
On Wed, Dec 14, 2011, at 06:36, Eric S. Raymond wrote:
> Daniel Shahaf :
> > Replace requires a node to already exist at the target path.
> >
> > Add requires a node to not already exist.
>
> OK, when you say "require", what do you mean? Just that if these conditions
> fail the node should not b
C. Michael Pilato :
> The "replace"
> action found in the dumpfile is just a compacting of some delete operation
> and a subsequent add or copy into a single verb, and that only because it
> helps sequential processors of the dump stream
Daniel Shahaf :
> Replace requires a node to already exist at the target path.
>
> Add requires a node to not already exist.
OK, when you say "require", what do you mean? Just that if these conditions
fail the node should not be modified?
> (container == node)
I see what you mean, but I think
On Tue, Dec 13, 2011 at 11:52 PM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Tue, Dec 13, 2011 at 22:04:33 +0100:
[...]
>> And even:
>>
>> $ svn mv some/file.txt some/otherfile.txt
>> $ svn mv some/otherfile.txt some/file.txt
>> $ svn ci -m "Replace some/file.txt with a copy of itself."
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 16:24:00 -0500:
> Here's what's going on. [...]
Thanks for the background; interesting. I've just read it and will read
it again more carefully tomorrow.
Johan Corveleyn wrote on Tue, Dec 13, 2011 at 22:04:33 +0100:
> On Tue, Dec 13, 2011 at 8:16 PM, Daniel Shahaf
> wrote:
> > C. Michael Pilato wrote on Tue, Dec 13, 2011 at 14:01:45 -0500:
> >> On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
> >> > C. Michael Pilato :
> >> >>> Does a file replace d
Daniel Shahaf :
> Eric S. Raymond wrote on Tue, Dec 13, 2011 at 13:34:03 -0500:
> > Self-defense, I assure you. I'm attempting to build a better SVN-to-DVCS
> > converter than exists anywhere now, and the best way to understand the
> > dump format well enough to do that is to document it in detail
On Tue, Dec 13, 2011 at 8:16 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Tue, Dec 13, 2011 at 14:01:45 -0500:
>> On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
>> > C. Michael Pilato :
>> >>> Does a file replace differ in any way from a delete plus add of the new
>> >>> text?
>> >>
>> >
C. Michael Pilato wrote on Tue, Dec 13, 2011 at 14:01:45 -0500:
> On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
> > C. Michael Pilato :
> >>> Does a file replace differ in any way from a delete plus add of the new
> >>> text?
> >>
> >> In Subversion, yes. A replacement is, like an add or a delet
On 12/13/2011 01:25 PM, Eric S. Raymond wrote:
> C. Michael Pilato :
>>> Does a file replace differ in any way from a delete plus add of the new
>>> text?
>>
>> In Subversion, yes. A replacement is, like an add or a delete, an operation
>> at the node level, not an operation on the contents of th
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 13:34:03 -0500:
> Self-defense, I assure you. I'm attempting to build a better SVN-to-DVCS
> converter than exists anywhere now, and the best way to understand the
> dump format well enough to do that is to document it in detail.
Curious if you also i
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 13:30:10 -0500:
> Daniel Shahaf :
> > Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
> > > Yes, but in a single copy command? My experience is that every one copy
> > > operation done from the CLI triggers a commit.
> >
> > Not every s
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 13:25:13 -0500:
> C. Michael Pilato :
> > > Does a file replace differ in any way from a delete plus add of the new
> > > text?
> >
> > In Subversion, yes. A replacement is, like an add or a delete, an operation
> > at the node level, not an operatio
Greg Stein :
> >I have commit
> > privileges on the Subversion repo; I was given them in connection
> > with svncutter. I'm willing to fix up that file, but want to check
> > that I wouldn't be stepping on any toes by doing so.
>
> Process-wise,
Daniel Shahaf :
> Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
> > Yes, but in a single copy command? My experience is that every one copy
> > operation done from the CLI triggers a commit.
>
> Not every single 'svn cp' invocation triggers a commit.
I've never been able to stop
C. Michael Pilato :
> > Does a file replace differ in any way from a delete plus add of the new
> > text?
>
> In Subversion, yes. A replacement is, like an add or a delete, an operation
> at the node level, not an operation on the contents of that node. A replace
> is an addition of a new objec
On Dec 13, 2011 2:14 AM, "Eric S. Raymond" wrote:
>
> I have just finished writing a full parser for Subversion dumpfiles.
> The next release of reposurgeon will have the ability to read them
> directly, though not to write them.
>
> In the process, I've looked very closely at the file
>
>
https:/
On Dec 13, 2011, at 16:37 , Daniel Shahaf wrote:
> Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
>> Yes, but in a single copy command? My experience is that every one copy
>> operation done from the CLI triggers a commit.
>
> Not every single 'svn cp' invocation triggers a comm
Eric S. Raymond wrote on Tue, Dec 13, 2011 at 09:44:59 -0500:
> Yes, but in a single copy command? My experience is that every one copy
> operation done from the CLI triggers a commit.
Not every single 'svn cp' invocation triggers a commit.
And, by the way, dumpfiles need to represent things th
On 12/13/2011 09:44 AM, Eric S. Raymond wrote:
> Philip Martin :
>> e...@thyrsus.com (Eric S. Raymond) writes:
>>
>>> # The "replace" action [?is only issued with directory copies, and?]
>>> # signifies that the existing contents of the directory should be
>>> # removed before the copy.
>>
>> Repla
Philip Martin :
> e...@thyrsus.com (Eric S. Raymond) writes:
>
> > # The "replace" action [?is only issued with directory copies, and?]
> > # signifies that the existing contents of the directory should be
> > # removed before the copy.
>
> Replace applies to files as well.
Does a file replace d
e...@thyrsus.com (Eric S. Raymond) writes:
> # The "replace" action [?is only issued with directory copies, and?]
> # signifies that the existing contents of the directory should be
> # removed before the copy.
Replace applies to files as well.
> # Interpreting copyfrom_path for file copies is s
I have just finished writing a full parser for Subversion dumpfiles.
The next release of reposurgeon will have the ability to read them
directly, though not to write them.
In the process, I've looked very closely at the file
https://svn.apache.org/repos/asf/subversion/trunk/notes/dump-load-fo
38 matches
Mail list logo
