headers
Daniel Torreblanca | 1 Sep 2008 07:23
Picon
Gravatar

Re: Problem building subversion

On Sun, Aug 31, 2008 at 3:04 PM, Robert Dailey <rcdailey <at> gmail.com> wrote:
> Hi,
>
> I'm trying to build on Linux, and I'm getting the following error:
>
> /home/robert/subversion/src/subversion-1.5.2/libtool: line 1322: LANG:
> command not found
> make: *** [subversion/libsvn_subr/atomic.lo] Error 1
>
>
> What exactly could be causing this? Thanks in advance.

What is LANG or LANGUAGE set to in your env settings? If you have a
non-standard value in there I think it might break libtool.
Permalink | Reply | 0 comments |
headers
Stephen Butler | 1 Sep 2008 10:08
Picon

Re: tree-conflicts: please review to determine desired behaviour in detail

Quoting Neels Hofmeyr <neels <at> elego.de>:

> Hi tree-conflicts,
>
> I am going through the tree-conflicts tests that use deep_trees (in
> subversion/tests/cmdline/update_tests.py, switch_tests.py and   
> merge_tests.py).
>
> Currently, these pass the exact behaviour that the svn tree-conflicts branch
> shows now (r32837). I want to change the tests so that they will pass the
> actually desired behaviour, showing what still needs to be fixed.
>
> But, when going into detail, it is not quite easy to determine the desired
> behaviour.
>
> I'm pasting the expected trees from the tests as they are now, which show
> the behaviour of svn as it is now (r32837), and add my comments (see
> attached file). Please review to death.
>
> Thanks!
> ~Neels

Hi Neels,

Here are my comments on the update behavior.  I'll start with the first
two test functions to get the ball rolling.

Following notes/tree-conflicts/detection.txt, we want 'svn update' to skip
any directory scheduled for deletion, and to instead record the tree
conflict in the parent directory.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Foad | 1 Sep 2008 13:44

Re: Deprecated functions should say what replaces them [was: An unexpected effect of new 'deprecated' tags.]

Stefan Küng wrote:
> Arfrever Frehtes Taifersar Arahesis wrote:
[...]
> > Maybe s/svn_client_get_commit_log2_t/log_msg_func2/.

> Thanks for the review. New patch attached which contains your improvements.

+1. Go ahead and commit it, Stefan. And thanks.

- Julian
Permalink | Reply | 0 comments |
headers
Senthil Kumaran S | 1 Sep 2008 14:05
Favicon

Re: Subversion sometimes needlessly asks for confirmation to store already stored plaintext passwords


Hi Karl,

Karl Fogel wrote:
> +      /* Nothing was present in the auth cache, so indicate that these
> +         credentials should be saved if saving is allowed by the run-time
> +         configuration. */
> 
> I'm just saying that it would be a bit better if that kind of
> explanation were collected at the variable's declaration, so the reader
> could understand the full semantics from the start -- instead of having
> to collect the information bit by bit from reading through the code.
> It's not a big deal, though; I think it's pretty clear as-is.

The updated patch has more clarification in the doc string for 'need_to_save'
variable. Please let me know if the patch is good so that I can commit it to trunk.

[[[
Fix unnecessary plaintext password saving prompt when the username
is supplied on the command line and the password is already cached.

* subversion/libsvn_subr/simple_providers.c
  (simple_username_get): New function to get username for simple provider.
  (svn_auth__simple_first_creds_helper): Start out with need_to_save = FALSE.
   The old code did set creds->may_save to TRUE whenever a username
   was supplied on the command line, regardless of whether a password
   was already cached or not. Here we check for different combinations
   of username and password either supplied in the command line or
   already cached in the auth area, based on that we toggle creds->may_save
   through need_to_save.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Arfrever Frehtes Taifersar Arahesis | 1 Sep 2008 16:11
Picon

Re: Problem building subversion

2008-08-31 21:04:17 Robert Dailey napisał(a):
> Hi,
> 
> I'm trying to build on Linux, and I'm getting the following error:
> 
> /home/robert/subversion/src/subversion-1.5.2/libtool: line 1322: LANG:
> command not found
> make: *** [subversion/libsvn_subr/atomic.lo] Error 1
> 
> 
> What exactly could be causing this? Thanks in advance.

This problem isn't related to development of Subversion and should be
discussed on users <at> subversion.tigris.org mailing list.

--

-- 
Arfrever Frehtes Taifersar Arahesis
Permalink | Reply | 0 comments |
headers
Stephen Butler | 1 Sep 2008 17:36
Picon

Re: tree-conflicts: please review to determine desired behaviour in detail

Quoting Julian Foad <julianfoad <at> btopenworld.com>:

> On Mon, 2008-09-01 at 10:08 +0200, Stephen Butler wrote:
>> Quoting Neels Hofmeyr <neels <at> elego.de>:

[...]

>> Following notes/tree-conflicts/detection.txt, we want 'svn update' to skip
>> any directory scheduled for deletion, and to instead record the tree
>> conflict in the parent directory.
>
> Also, similarly, I claim we want 'svn update' to skip any FILE scheduled
> for deletion, and to instead record the tree conflict in the parent
> directory. Yes?

I agree.  We should be consistent in handling files and directories.  After
all, a file is just a very simple tree!

The current behavior for files on the tree-conflicts branch (where we carry
out each update action immediately) is based on the principle that the user
can't reject an update.  The principle is still valid, but it's better to
postpone the update action.

[...]

> Yes, except 'alpha' is a tree conflict victim (it was previously
> scheduled for delete), so it can't be updated and should be skipped:
>
> [[[
>    expected_output = wc.State('', {
(Continue reading)

Permalink | Reply | 11 comments |
headers
Arfrever Frehtes Taifersar Arahesis | 1 Sep 2008 17:39
Picon

Incorrect handling of svn:mergeinfo during merging on the svnpatch-diff branch

I discovered 2 bugs in handling of svn:mergeinfo when I was performing some
merges on the svnpatch-diff branch.

1. Addition of incorrect svn:mergeinfo on some files or directories:

Steps to reproduce:
 svn co -r32624 https://svn.collab.net/repos/svn/branches/svnpatch-diff subversion-svnpatch-diff-r32624
 cd subversion-svnpatch-diff-r32624
 svn merge -r32500:32620 ^/trunk

This merge adds incorrect svn:mergeinfo on:
 build.conf
 subversion/include
 subversion/libsvn_subr
 subversion/tests/libsvn_subr

These files / directories don't have svn:mergeinfo before merging.
After merging, svn:mergeinfo on these files / directories doesn't contain:
 /trunk:1-31375,31378-32620

(Next `svn merge ^/trunk` would try to merge r25664:30782 from trunk which causes
many conflicts.)

2. Incomplete reversion of changes during reverse merging:

Steps to reproduce:
 svn co -r32625 https://svn.collab.net/repos/svn/branches/svnpatch-diff subversion-svnpatch-diff-r32625
 cd subversion-svnpatch-diff-r32625
 svn merge -c-32625 ^/branches/svnpatch-diff
(Continue reading)

Permalink | Reply | 13 comments |
headers
Arfrever Frehtes Taifersar Arahesis | 1 Sep 2008 17:46
Picon

Re: Incorrect handling of svn:mergeinfo during merging on the svnpatch-diff branch

2008-09-01 17:39:20 Arfrever Frehtes Taifersar Arahesis napisał(a):
> I discovered 2 bugs in handling of svn:mergeinfo when I was performing some
> merges on the svnpatch-diff branch.
> 
> 1. Addition of incorrect svn:mergeinfo on some files or directories:
> 
> Steps to reproduce:
>  svn co -r32624 https://svn.collab.net/repos/svn/branches/svnpatch-diff subversion-svnpatch-diff-r32624
>  cd subversion-svnpatch-diff-r32624
>  svn merge -r32500:32620 ^/trunk
> 
> This merge adds incorrect svn:mergeinfo on:
>  build.conf
>  subversion/include
>  subversion/libsvn_subr
>  subversion/tests/libsvn_subr
> 
> These files / directories don't have svn:mergeinfo before merging.
> After merging, svn:mergeinfo on these files / directories doesn't contain:
>  /trunk:1-31375,31378-32620
> 
> (Next `svn merge ^/trunk` would try to merge r25664:30782 from trunk which causes
> many conflicts.)
> 
> 
> 2. Incomplete reversion of changes during reverse merging:
> 
> Steps to reproduce:
>  svn co -r32625 https://svn.collab.net/repos/svn/branches/svnpatch-diff subversion-svnpatch-diff-r32625
>  cd subversion-svnpatch-diff-r32625
(Continue reading)

Permalink | Reply | 9 comments |
headers
Hyrum K. Wright | 1 Sep 2008 18:21
Picon

Proposal: --no-props switch for 'log', 'st' and 'diff'

In using merge tracking with 1.5.x and other branches, I've occasionally been
annoyed by the fact that mergeinfo mods can often overshadow the meat of a
change.  I'd like to add a '--no-props' flag to 'log', 'st', and 'diff' which
would simply cause the subcommand to ignore property changes.  It wouldn't be
the default, but it would clean up output and make using merge tracking a bit
easier.

I envision '--no-props' to be an all-or-nothing measure, initially, but we if
the demand was there, we could further expand it to '--without-prop FOO' which
would only omit changes to property FOO.

Thoughts?

-Hyrum
Permalink | Reply | 32 comments |
headers
Arfrever Frehtes Taifersar Arahesis | 1 Sep 2008 18:24
Picon

Re: Proposal: --no-props switch for 'log', 'st' and 'diff'

2008-09-01 18:21:05 Hyrum K. Wright napisał(a):
> In using merge tracking with 1.5.x and other branches, I've occasionally been
> annoyed by the fact that mergeinfo mods can often overshadow the meat of a
> change.  I'd like to add a '--no-props' flag to 'log', 'st', and 'diff' which
> would simply cause the subcommand to ignore property changes.  It wouldn't be
> the default, but it would clean up output and make using merge tracking a bit
> easier.
> 
> I envision '--no-props' to be an all-or-nothing measure, initially, but we if
> the demand was there, we could further expand it to '--without-prop FOO' which
> would only omit changes to property FOO.
> 
> Thoughts?

+1.

--

-- 
Arfrever Frehtes Taifersar Arahesis
Permalink | Reply | 0 comments |

Gmane