On Tue, Jul 12, 2011 at 12:50, Greg Stein wrote:
> On Tue, Jul 12, 2011 at 10:32, C. Michael Pilato wrote:
>...
>> What to do about Serf? I'd like to think that Greg could wrap up his work
>> on the single remaining blocking issue in the next week or so. I've already
>> heard (via Hyrum) that h
On Tue, Jul 12, 2011 at 4:16 PM, wrote:
> Author: blair
> Revision: 1145773
> Modified property: svn:log
>
> Modified: svn:log at Tue Jul 12 21:16:32 2011
> --
> --- svn:log (original)
> +++ svn:log Tue Jul 12 21:16:32 20
On Jul 12, 2011, at 12:05 PM, Johan Corveleyn wrote:
> On Tue, Jul 12, 2011 at 8:42 PM, wrote:
>>
>> *
>> * Invoke svn_repos_node_from_baton() on @a edit_baton to obtain the root
>> - * node afterwards.
>> + * node afterwords.
>
> sp?
>
> (not that I have such a high OCD level to make me r
On 12 Jul 2011, at 15:02, Julian Foad wrote:
> On Mon, 2011-07-11 at 12:23 +0100, Julian Foad wrote:
>> On Sat, 2011-07-09, Barry Scott wrote:
>>> svn built with ./configure --prefix=/usr/local --enable-debug on
>>> Fedora 15 x86_64.
>>
>> Hi Barry. This stack trace and info is useful, ...
>>
> On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright
> wrote:
>
> > Because I'm a nice guy (and to allow people time to comment),
> I'll
> > wait until tomorrow morning to create the branch, but plan on it
> then.
>
> +1
Is that a +1 that Hyrum is a nice guy, or that he will wait, or that he shou
> On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright
> wrote:
> > On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard
> wrote:
> >> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
> wrote:
> >>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard
> wrote:
>
> Finally, in your new design do not
I am reticent to comment to the developer community directly (and you
can see it has only happened a couple of times in 10 years), but as
someone who's been focused for the life of Subversion on its
implementation for enterprises and has been the source of impetus for
much of what CollabNet has con
On Tue, Jul 12, 2011 at 8:42 PM, wrote:
> Author: blair
> Date: Tue Jul 12 18:42:19 2011
> New Revision: 1145716
>
> URL: http://svn.apache.org/viewvc?rev=1145716&view=rev
> Log:
> Minor spelling fixes.
>
> * subversion/include/svn_fs.h,
> * subversion/include/svn_repos.h:
> Fix a few spelling m
On 07/12/2011 02:46 PM, Blair Zajac wrote:
>
> On Jul 12, 2011, at 7:42 AM, Hyrum K Wright wrote:
>
>> One question that I have is regarding housekeeping. Do we have any
>> actions which should be done on trunk (file renames, whitespace
>> cleaning, mergeinfo pruning, etc), which will improve ou
On Jul 12, 2011, at 7:42 AM, Hyrum K Wright wrote:
> One question that I have is regarding housekeeping. Do we have any
> actions which should be done on trunk (file renames, whitespace
> cleaning, mergeinfo pruning, etc), which will improve our experience
> when merging to the branch?
I took m
On Jul 12, 2011, at 12:34 PM, Daniel Shahaf wrote:
> Why can't you --- as Paul already said --- just enforce a policy "Don't
> do subtree merges"?
>
>> If newmerge is successful and we want people to
>> move to it, we can force the conversion by asking "svn" to read the
>> old merginfo and write
On Tue, Jul 12, 2011 at 1:12 PM, Julian Foad wrote:
> I see three main thrusts behind the whole proposal, that are each much
> more significant than any of the specific concrete ideas. The first is
> that it's time to try some experiments in merge tracking.
+1
> The second is
> that restricting
On Tue, Jul 12, 2011 at 1:05 PM, Andy Singleton wrote:
> Log and blame will not be problems. My proposal does not change log or
> blame. They will still work fine if you apply newmerge. The revisions and
> authors and commit messages are still in the repository in the same place,
> and log and
On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright wrote:
> On Tue, Jul 12, 2011 at 9:42 AM, Hyrum K Wright wrote:
>> On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato
>> wrote:
>>> The issue tracker currently has *no* non-Serf-related blocker issues open.
>>> Per prior agreement, this effective
I see three main thrusts behind the whole proposal, that are each much
more significant than any of the specific concrete ideas. The first is
that it's time to try some experiments in merge tracking. The second is
that restricting merges (primarily to the scope of "a whole branch") is
key to redu
On Tue, Jul 12, 2011 at 11:55 AM, Andy Singleton wrote:
> On 7/12/2011 11:43 AM, Stefan Sperling wrote:
>>
>> On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
>>>
>>> If you want to keep it as a mergeable branch (clearly relevant),
>>> then maybe it's better just to add on as "svn
On Mon, Jul 11, 2011 at 1:57 PM, Andy Singleton wrote:
> I received a lot of good comments, and I will batch up my responses in this
> note.
>
> From Stefan, essentially "Can you improve the existing merge"? Yes, I think
> that we can start with the existing merge code.
>
> However, I also think
Log and blame will not be problems. My proposal does not change log
or blame. They will still work fine if you apply newmerge. The
revisions and authors and commit messages are still in the repository in
the same place, and log and blame will still show them.
There are only two cases that
On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright wrote:
> On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard wrote:
>> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
>> wrote:
>>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
Finally, in your new design do not forget about th
On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard wrote:
> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright
> wrote:
>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
>>>
>>> Finally, in your new design do not forget about things like log -g and
>>> blame -g, as well as the mergeinfo comm
On Tue, Jul 12, 2011 at 10:32, C. Michael Pilato wrote:
>...
> realize that we'd like to see the tracker sit quiet (blocker-wise) for a
> week or so before saying "ship the RC", but I think we need to face some
> realities:
>
> - blocker-class bugs can -- and will -- crop up after we branch.
>
>
On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright wrote:
> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
>>
>> Finally, in your new design do not forget about things like log -g and
>> blame -g, as well as the mergeinfo command. These features are all
>> necessary parts of a merge tracki
On Tue, Jul 12, 2011 at 12:40 PM, Andy Singleton wrote:
> Good point. If we allow foreign merges, then "log" and "blame" are not
> going to work well. They will show changes coming from the merge, rather
> than from the original commit. Fine. I'm willing to give up those details,
> because me
On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard wrote:
>
> Finally, in your new design do not forget about things like log -g and
> blame -g, as well as the mergeinfo command. These features are all
> necessary parts of a merge tracking plan and must have answers from
> the first release.
Really
Andy Singleton wrote on Tue, Jul 12, 2011 at 12:16:26 -0400:
> I am only asking you to give up ONE THING: subtree merginfo. To
> succeed, we have to get rid of both parts of it. We have to get rid
> of the subtree info, and we have to get rid of the fussy little
> merginfo format.
Why is the
On 7/12/2011 12:25 PM, Mark Phippard wrote:
On Tue, Jul 12, 2011 at 12:16 PM, Andy Singleton wrote:
Mark, I agree with you that the existing merge will work better if we apply
some restrictions. I can see that the project is already going that way,
and maybe it is good to continue in that di
On Tue, Jul 12, 2011 at 12:22 PM, Hyrum K Wright wrote:
> Because I'm a nice guy (and to allow people time to comment), I'll
> wait until tomorrow morning to create the branch, but plan on it then.
+1
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
On Tue, Jul 12, 2011 at 12:16 PM, Andy Singleton wrote:
> Mark, I agree with you that the existing merge will work better if we apply
> some restrictions. I can see that the project is already going that way,
> and maybe it is good to continue in that direction. As a user, I would find
> that h
On Tue, Jul 12, 2011 at 9:42 AM, Hyrum K Wright wrote:
> On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato
> wrote:
>> The issue tracker currently has *no* non-Serf-related blocker issues open.
>> Per prior agreement, this effectively means that there are no known
>> blockers, as we have a cont
On Fri, Jul 8, 2011 at 1:04 PM, Julian Foad wrote:
> On Fri, 2011-07-01, Paul Burba wrote:
>> Paul Burba wrote:
>> > Julian Foad wrote:
>> >> I will just ask once more: as a matter of principle, are we comfortable
>> >> it's OK to provide only an indication that "the server did in fact do
>> >> th
On 7/12/2011 11:54 AM, Mark Phippard wrote:
On Tue, Jul 12, 2011 at 11:29 AM, Andy Singleton wrote:
I don't think that we will need to force anyone to give up the old merge.
If and when the newmerge is better, they will migrate on their own. I
think merge is an important concern for many u
Le 11 juillet 2011 16:20:38 Philip Martin a écrit :
> Philip Martin writes:
> > However this object code is dynamically loaded by Perl at runtime so
> > it's not impossible that the Perl compiler flags need to be applied. It
> > seems to me that Subversion is responsible for ensuring that this is
On 7/12/2011 11:43 AM, Stefan Sperling wrote:
On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
If you want to keep it as a mergeable branch (clearly relevant),
then maybe it's better just to add on as "svn newmerge" from the
beginning. If that approach is recommended, then maybe
On Tue, Jul 12, 2011 at 11:29 AM, Andy Singleton wrote:
> I don't think that we will need to force anyone to give up the old merge.
> If and when the newmerge is better, they will migrate on their own. I
> think merge is an important concern for many users and they will migrate
> quickly if the
On Tue, Jul 12, 2011 at 11:29:57AM -0400, Andy Singleton wrote:
> If you want to keep it as a mergeable branch (clearly relevant),
> then maybe it's better just to add on as "svn newmerge" from the
> beginning. If that approach is recommended, then maybe someone can
> help by adding the stub for t
On Jul 12, 2011, at 11:29 AM, Andy Singleton wrote:
> My original idea was to make a new executable file called "newmerge". It
> would be an external script, and if you want to use it, you just need that
> extra script. However, I was planning on building it from the C code that is
> in "svn
My original idea was to make a new executable file called "newmerge".
It would be an external script, and if you want to use it, you just need
that extra script. However, I was planning on building it from the C
code that is in "svn merge" right now, rather than python or perl.
Using the ex
Failed to build Revision: 1145623.
Mark Phippard wrote on Tue, Jul 12, 2011 at 11:00:10 -0400:
> We can just have a way to not allow users to use the features of
> existing merge that we do not want them to use. The existing merge
> command already supports the proposed simple syntax.
+1
On Tue, Jul 12, 2011 at 10:52 AM, Julian Foad wrote:
> A script has the advantage that it could be tried and even rolled out by
> people who are still using 1.6.x.
>
> None of that is a reason not to start a branch.
+1 on the branch. But wouldn't it make sense to defer creating the
branch for a
On 07/12/2011 10:52 AM, Julian Foad wrote:
> Note that there are other possible ways of working, which can be tried
> as well as or instead of the branch. An external script is another good
> option, like the way 'svnmerge.py' existed before the current built-in
> merge tracking. I was talking to
C. Michael Pilato wrote:
> On 07/12/2011 09:40 AM, Hyrum K Wright wrote:
> > We should probably consider having Andrew and his group do their work
> > on a branch in our repository.
>
> +1
+1. I can create a branch, called ... well, the basic nature of this
proposal is simplifying the scope of w
On Tue, Jun 28, 2011 at 02:23:35PM +0200, Stefan Sperling wrote:
> On Mon, Jun 27, 2011 at 02:03:18PM +0100, Philip Martin wrote:
> > Stefan Sperling writes:
> >
> > > Maybe we should tell people that they should only use update if
> > > they have local mods, and perform a checkout otherwise.
> >
On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato wrote:
> The issue tracker currently has *no* non-Serf-related blocker issues open.
> Per prior agreement, this effectively means that there are no known
> blockers, as we have a contingency plan for Serf already (un-default it). I
> realize that
On 07/12/2011 09:40 AM, Hyrum K Wright wrote:
> We should probably consider having Andrew and his group do their work
> on a branch in our repository.
+1
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital s
The issue tracker currently has *no* non-Serf-related blocker issues open.
Per prior agreement, this effectively means that there are no known
blockers, as we have a contingency plan for Serf already (un-default it). I
realize that we'd like to see the tracker sit quiet (blocker-wise) for a
week o
This change and the next one add the "api" keyword to issues that can't
be first fixed in a patch release. (IOW, that can first be fixed in
a .0 or .0.0 release.)
Probably at least some of those are doing to be wrong or controversial
(eg, possibly the bindings issue shouldn't have been labeled) -
On Mon, 2011-07-11 at 12:23 +0100, Julian Foad wrote:
> On Sat, 2011-07-09, Barry Scott wrote:
> > svn built with ./configure --prefix=/usr/local --enable-debug on
> > Fedora 15 x86_64.
>
> Hi Barry. This stack trace and info is useful, ...
>
> > Let me know if you want to run this yourself. I c
On Mon, Jul 11, 2011 at 11:51 AM, C. Michael Pilato wrote:
> On 07/11/2011 11:46 AM, Andy Singleton wrote:
>>
>> Many developers are moving from Subversion to other SCM systems that have
>> better merge capabilities. I have posted an article with a proposal to fix
>> this problem, here:
>>
>> htt
On Tue, Jul 12, 2011 at 02:01:27PM +0200, Stefan Sperling wrote:
> There already exist issues for this feature, in two different flavours:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3625
> http://subversion.tigris.org/issues/show_bug.cgi?id=3625
Oops, the second one should have been:
ht
On Tue, Jul 12, 2011 at 09:25:36AM +, Bolstridge, Andrew wrote:
>
>
> > -Original Message-
> > From: Andy Singleton [mailto:a...@assembla.com]
> > Sent: 11 July 2011 21:55
> > To: Bob Archer
> > Cc: dev@subversion.apache.org
> > Subject: Re: It's time to fix Subversion Merge
> >
> >
Log
[[[
* subversion/svnadmin/main.c
(parse_args): Change error strings to one that is already translated
in the po files. Also use _().
Patch by: Noorul Islam K M
]]]
Thanks and Regards
Noorul
Index: subversion/svnadmin/main.c
===
If it's as simple as you say then why hasn't it been implemented yet?
Bolstridge, Andrew wrote on Tue, Jul 12, 2011 at 09:25:36 +:
>
>
> > -Original Message-
> > From: Andy Singleton [mailto:a...@assembla.com]
> > Sent: 11 July 2011 21:55
> > To: Bob Archer
> > Cc: dev@subversion.apa
I am out of the office from Sun 07/10/2011 until Tue 07/19/2011.
I am out on vacation, returning on May 2nd. My access to email is limited.
For RELM issues during this interval, please contact Sam Lee.
Nick.
Note: This is an automated response to your message "[l10n] Translation
status repo
> -Original Message-
> From: Andy Singleton [mailto:a...@assembla.com]
> Sent: 11 July 2011 21:55
> To: Bob Archer
> Cc: dev@subversion.apache.org
> Subject: Re: It's time to fix Subversion Merge
>
> If you want offline commit and private repositories, you can use git or
> mercurial. We
Daniel Shahaf writes:
> Where does that happen? svn_repos_upgrade2() calls get_repos() which
> calls lock_repos() which is a no-op if the underlying filesystem is
> FSFS.
My mistake, I skipped over the bdb-only line.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
On Tue, Jul 12, 2011 at 02:46, Bert Huijben wrote:
>> >> Log:
>> >> Fix calculation X-SVN-VR-Base request header in ra_serf.
>> >>
>> >> This commit reverts r1142065 and r1143089.
>> >>
>> >> * subversion/libsvn_ra_serf/update.c
>> >> (report_dir_t): Remove repos_relpath.
>> >> (report_context
I added _(), changed the string to one that is already translated in the
po files, and committed r1145478.
Log
[[[
* subversion/svnadmin/main.c
(subcommand_lslocks): Return better error message when too many
arguments are passed to 'svnadmin lslocks'.
Patch by: Noorul Islam K M
]]]
Index: subversion/svnadmin/main.c
===
--- subvers
Using 1.6 client
noorul@noorul:/tmp/wc/repos$ ls a
ls: cannot access a: No such file or directory
noorul@noorul:/tmp/wc/repos$ svn cl testlist a
svn: warning: 'a' is not under version control
noorul@noorul:/tmp/wc/repos$ svn cl a --remove
svn: warning: 'a' is not under version con
60 matches
Mail list logo
