Re: A problem trying to use svn:// and http:// for a same repository at the same time

[谢带达]

Thank you Ryan.

I read the sections:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.html
and
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
The multiple access methods section seems not to help me to resolve my
question.
About the mirror repository, I will try it later. But for easy, I hope the
remote team and the local team could use the same repository. Thank you.

Regards,
David

2010/12/20 Ryan Schmidt 

>
> On Dec 20, 2010, at 01:03, David wrote:
>
> > We use http:// for local team. Currently another team at another site
> > need to visit our repository to cooperate.
> > They complain about the slow speed of diff, merge and tag. So I want
> > to turn on svn:// for them while http:// for us.
> > It seems to be posibble, right?
>
> Certainly. Have you read the section of the book about supporting multiple
> access methods?
>
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.html
>
>
> If speed is the concern, a different solution might be to give your remote
> team a local read-only mirror of your repository, with write-through
> proxying back to your main repository. You can read about repository
> replication here:
>
>
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
>
>
>
>

Re: newbie doubt.. problem with import in windows

[sajan]

> URLs always have forward slashes. Try something like:
>  svn import myproject file:///C:/code/svnrepo/myproject
>
thanks Stefan,
sajan

Re: A problem trying to use svn:// and http:// for a same repository at the same time

[Stefan Sperling]

On Tue, Dec 21, 2010 at 04:25:55PM +0800, 谢带达 wrote:
> Thank you Stefan.
> 
> I start svnserve this way:
> 
> /local/svnroot/repository/one/conf/svnserve.conf
> [general]
> anon-access =
> auth-access = write
> password-db = passwd
> authz-db = authz
> /local/svnroot/repository/one/conf/authz
> [/]
> test = rw
> * =
> 
> /local/svnroot/repository/one/conf/passwd
> [users]
> test = test
> 
> And then I start svnserve with root account:
> /local/svnroot/subversion/bin/svnserve -d --listen-host 172.18.127.148
> --root /local/svnroot/repository
> 
> Yes I could connet to :
> svn://172.18.127.148/test
> svn://172.18.127.148/one
> 
> The problem is that it show "Item is not readble" when I try to show log via
> TSVN.
> The only difference between Repository one and Repository test is that the
> former is created with --pre-1.5-compatible but the latter not.
> 3 snaps are attached for your reference.

I think this means that something is wrong with your authz configuration.
Can you try to disable authz to see if it works without?

Stefan

Re: File Obstructed by Symbolic Link Prevents Submitting Unrelated Changelists

[Daniel Shahaf]

Nick wrote on Mon, Dec 20, 2010 at 18:17:02 -0500:
> On Mon, 2010-12-20 at 19:19 +0200, Daniel Shahaf wrote:
> > I can reproduce this with trunk:
> > [[[
> > % cd wc1/trunk/
> > % touch a b c d
> > % $svn add -q ?
> > % $svn ci -q -m add
> > % echo line1  >a >b
> > % rm c; ln -s d c
> > % $svn cl -q cltest a b
> > % $svn ci --cl cltest
> > subversion/svn/commit-cmd.c:156: (apr_err=145001)
> > subversion/libsvn_client/commit.c:846: (apr_err=145001)
> > svn: Commit failed (details follow):
> > subversion/libsvn_client/commit_util.c:1097: (apr_err=145001)
> > subversion/libsvn_client/commit_util.c:891: (apr_err=145001)
> > subversion/libsvn_client/commit_util.c:455: (apr_err=145001)
> > svn: Entry '/tmp/svn/wc1/trunk/c' has unexpectedly changed special
> > status
> > zsh: exit 1 $svn ci --cl cltest
> > % $svn ci --cl cltest -q -mm [ab]
> > %
> > ]]]
> > 
> > Could you, please, file an issue for this (if there isn't one already
> > filed)?
> > 
> > Thanks,
> > 
> > Daniel
> > (I can't look at this right now; but if there's an issue then I or
> > someone else will eventually get to it)
> 
> Thanks for confirming Daniel!
> I had opened an issue for this last year, but it's in the
> subversion.tigris.org site:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3484 .
> 
> Is this OK?  Or should I open another issue in the apache.org tracker?
> 

That's okay.  (We have no apache.org tracker.)  I've updated some
fields, and I'll try to get around to look at it in more detail some
time.

> 

Re: File Obstructed by Symbolic Link Prevents Submitting Unrelated Changelists

[Daniel Shahaf]

Nick wrote on Mon, Dec 20, 2010 at 21:01:59 -0500:
> On Mon, 2010-12-20 at 17:34 -0600, Ryan Schmidt wrote:
> 
> > The Subversion project still uses the tigris.org issue tracker; it
> > does not yet use the apache.org issue tracker. See the yellow box on
> > this page:
> > 
> > http://subversion.apache.org/issue-tracker.html
> 
> 
> When I read that part of the page I wasn't sure if it was a mix of
> tigris.org and apache.org, or still entirely tigris.org.  Thanks for the
> clarification.

Fixed:
http://svn.apache.org/viewvc/subversion/site/publish/issue-tracker.html?r1=1051442&r2=1051441&pathrev=1051442

Re: Revisions being involved while comparing branches

[Daniel Shahaf]

'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies)

'dig the logs' is "lookup the copyfrom revisions of the tags, and run
log on replay.c for that revision range".  What's wrong with that?

Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100:
> Is there a direct way (via cmd line) to find out the revisions involved in
> the summary result of differencing two branches?
> 
> An easy example:
> 
> 
> 
> 
> svn diff
> http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos
> http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize
> 
> M
> http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c
> 
> 
> 
> The two tags were created in r1036188 and r1038150, but the replay.c file
> was modified  in
> http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005
> 
> Is there anyway to find out the 1037005 revision number without having to
> analyze the logs?

Merge tracking between several parallel branches

[Fredrik Orderud]

I have some questions regarding the status of the merge tracking
functionality in subversion 1.6.  Based on my understanding, it seems
like svn has good “automatic” support for merging between branches in
one direction, whereas cyclic/bidirectional merging requires a more
complex “reintegrate” + “record only” merge procedure. I am wondering
if this support also extends to scenarios with repeated merging
between several parallel release branches.

Does svn handle arbitrary "directed acyclic" merging between several
parallel branches, when merging is always conducted in the same
direction (e.g. from old to newer release branch)?

Does the “reintegrate” + “record only” merge procedure extend
gracefully to scenarios with arbitrary cyclic/bidirectional merging
between several parallel branches?

Thanks in advance,
Fredrik Orderud

An access permissions problem

[David Aldrich]

Hi

We host each of our  projects in a separate svn repo and control access 
permissions via Apache.

In one large project, we need to limit the visibility of a few confidential 
files.  We have done this by specifying something like:

[myproj:/trunk/ConfidentialFolder]
@myPrivilegedGroup = rw
* =

The problem with this is that the confidential files become visible to everyone 
when we create a branch. Of course, we could control the visibility of the 
branches by adding further directives but this becomes complex and hard to 
validate. So we think it is best to only set access permissions on entire 
repositories.

Therefore, we think a better solution would be to put the confidential files in 
their own repo and bring them into the large project with an external.  
However, I am not sure what happens when an external can't be resolved because 
access to the external repo is denied.

I would welcome any advice on this problem.

BR

David

Re: An access permissions problem

[David Weintraub]

It looks like the, branches, tags, and trunk directories are at the
root of your repository. What if you create the confidential branches
under their own folder under the branches and tags directories instead
of directly under those directories?

Then, you could specify it this way:

[myproj:/trunk/ConfidentialFolder]
@myPrivilegedGroup = rw
* =
[myproj:/branches/ConfidentialBranches]
@myPrivilegedGroup = rw
* =
[myproj:/tags/ConfidentialTags]
@myPrivilegedGroup = rw
* =

On Tue, Dec 21, 2010 at 9:46 AM, David Aldrich  wrote:
> Hi
>
>
>
> We host each of our  projects in a separate svn repo and control access
> permissions via Apache.
>
>
>
> In one large project, we need to limit the visibility of a few confidential
> files.  We have done this by specifying something like:
>
>
>
> [myproj:/trunk/ConfidentialFolder]
>
> @myPrivilegedGroup = rw
>
> * =
>
>
>
> The problem with this is that the confidential files become visible to
> everyone when we create a branch. Of course, we could control the visibility
> of the branches by adding further directives but this becomes complex and
> hard to validate. So we think it is best to only set access permissions on
> entire repositories.
>
>
>
> Therefore, we think a better solution would be to put the confidential files
> in their own repo and bring them into the large project with an external.
> However, I am not sure what happens when an external can’t be resolved
> because access to the external repo is denied.
>
>
>
> I would welcome any advice on this problem.
>
>
>
> BR
>
>
>
> David



-- 
David Weintraub
qazw...@gmail.com

RE: An access permissions problem

[David Aldrich]

Hi David

Thanks for your help. Yes, the branches, tags, and trunk directories are at the
root. In your suggestion, I am worried that a developer might create a branch 
containing ConfidentialFolder in /branches rather than in 
/branches/ConfidentialBranches, by mistake. Do you agree that is a problem?

David

-Original Message-
From: David Weintraub [mailto:qazw...@gmail.com] 
Sent: 21 December 2010 15:40
To: David Aldrich
Cc: users@subversion.apache.org
Subject: Re: An access permissions problem

It looks like the, branches, tags, and trunk directories are at the
root of your repository. What if you create the confidential branches
under their own folder under the branches and tags directories instead
of directly under those directories?

Then, you could specify it this way:

[myproj:/trunk/ConfidentialFolder]
@myPrivilegedGroup = rw
* =
[myproj:/branches/ConfidentialBranches]
@myPrivilegedGroup = rw
* =
[myproj:/tags/ConfidentialTags]
@myPrivilegedGroup = rw
* =

On Tue, Dec 21, 2010 at 9:46 AM, David Aldrich  wrote:
> Hi
>
>
>
> We host each of our  projects in a separate svn repo and control access
> permissions via Apache.
>
>
>
> In one large project, we need to limit the visibility of a few confidential
> files.  We have done this by specifying something like:
>
>
>
> [myproj:/trunk/ConfidentialFolder]
>
> @myPrivilegedGroup = rw
>
> * =
>
>
>
> The problem with this is that the confidential files become visible to
> everyone when we create a branch. Of course, we could control the visibility
> of the branches by adding further directives but this becomes complex and
> hard to validate. So we think it is best to only set access permissions on
> entire repositories.
>
>
>
> Therefore, we think a better solution would be to put the confidential files
> in their own repo and bring them into the large project with an external.
> However, I am not sure what happens when an external can't be resolved
> because access to the external repo is denied.
>
>
>
> I would welcome any advice on this problem.
>
>
>
> BR
>
>
>
> David



-- 
David Weintraub
qazw...@gmail.com


 Click 
https://www.mailcontrol.com/sr/m5HZpEx0TeXTndxI!oX7Ui!B!9hWdHWJSayi3ertgL1BdOqvXvhMeYlmF8vykjgUr+eZouLtF3paXEW7R1X!lw==
  to report this email as spam.

Re: File Obstructed by Symbolic Link Prevents Submitting Unrelated Changelists

[Nick]

On Tue, 2010-12-21 at 11:59 +0200, Daniel Shahaf wrote:
> I've updated some
> fields, and I'll try to get around to look at it in more detail some
> time.

I appreciate it, thanks!

Re: File Obstructed by Symbolic Link Prevents Submitting Unrelated Changelists

[Nick]

On Tue, 2010-12-21 at 12:02 +0200, Daniel Shahaf wrote:

> > When I read that part of the page I wasn't sure if it was a mix of
> > tigris.org and apache.org, or still entirely tigris.org.  Thanks for
> the
> > clarification.
> 
> Fixed:
> http://svn.apache.org/viewvc/subversion/site/publish/issue-tracker.html?r1=1051442&r2=1051441&pathrev=1051442


That reads much clearer to me now, thanks!

Re: An access permissions problem

[David Weintraub]

On Tue, Dec 21, 2010 at 10:59 AM, David Aldrich
 wrote:
> Thanks for your help. Yes, the branches, tags, and trunk directories are at 
> the root. In your suggestion, I am worried that a developer might create a 
> branch containing ConfidentialFolder in /branches rather than in 
> /branches/ConfidentialBranches, by mistake. Do you agree that is a problem?

Sure, that's a possible issue. One of the biggest problems with
Subversion is that it is almost impossible to delete any information
from the repository. You put in confidential information in the wrong
place, and you basically have to do a dump/filter/load to remove it
from the repository.

To solve this issue, you can create a pre-commit hook that will
prevent someone from copying the confidential information project to
the plain /branches branch.

When a copy is done, svnlook will list where the copy is from, and
your hook can intercept this information.

I don't think my kitchen-sink pre-commit hook can be configured to
prevent this from happening. My script can prevent particular people
from creating a tag or branch, but never looks at the "to"
information.

You'll have to write your own hook script. Fortunately, it isn't too
difficult -- especially since you're just checking for a very simple
thing. Do you see an "A' transaction where the from is from the
confidential directory and the "to" is to the branches directory? If
so, fail the transaction.

-- 
David Weintraub
qazw...@gmail.com

SVN BUG : Lines disappeared after update and check in

[riad benmouhoub]

Hi,

I experienced the following behavior with SVN. The steps i did are :

1- I made changes in a file
2- updated the file
3- Checked in the file after the merge succeeded
4- In the resulting file 6 lines disappeared.

Is it considered as a bug?
has anyone experienced such a behavior?

Thanks

Riad

Re: svn: database disk image is malformed

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, Dec 18, 2010 at 20:41:43 +0200:
> CC += dev@
> 
> Stefan Sperling wrote on Thu, Dec 16, 2010 at 18:49:22 +0100:
> > On Thu, Dec 16, 2010 at 05:03:00PM +0100, Rainer Dorsch wrote:
> > > I try to commit the change
> > > 
> > > $ svn commit -m "minor change"
> > > SendingREADME
> > > Transmitting file data .svn: Commit failed (details follow):
> > > svn: database disk image is malformed
> > > svn: database disk image is malformed
> > > $ 
> > > 
> > > And get an error back.
> ...
> > > I found several posts discussing the 
> > > 
> > >   svn: database disk image is malformed
> > > 
> > > issue. The best solution is saw is to dump the repository and create a 
> > > new one 
> > > from the dump.
> > >
> > > Is there an easier way to fix the problem in a robust manner? Does maybe 
> > > even 
> > > svn provide some fix scripts?
> > 
> > This error message is coming from sqlite, not from Subversion.
> > You probably have a broken sqlite database in the repository.
> > 
> > The only place I can think of where sqlite is used in FSFS is
> > the rep-cache.db file.
> 
> [ For future archeologists, format-5 fsfs repositories (which will
> created by Subversion 1.7) will also use sqlite for the revprops.db
> file. ]
> 
> > Have you got rep-sharing enabled on the repository?
> > See the file repos/db/fsfs.conf.
> > 
> > You can safely disable rep-sharing. Maybe this will get rid of the error.
> > If it does, try to recover the rep-sharing.db using sqlite (though I
> > don't know how you could do that). If you cannot recover rep-cache.db,
> > move it out of the way and Subversion will create a new rep-cache.db
> > sqlite database. But it will be empty.
> > 
> > Representation sharing is not required for a commit to succeed.
> > This would explain why you see a successful commit in spite of the error.
> > 
> 
> How about the second hunk of this patch then?
> 
> I haven't compiled it, and it abuses error codes (to use the
> specific error code that clients recognize), but is the idea sound?
> 
> [[[
> Index: subversion/libsvn_fs_fs/fs_fs.c
> ===
> --- subversion/libsvn_fs_fs/fs_fs.c   (revision 1044834)
> +++ subversion/libsvn_fs_fs/fs_fs.c   (working copy)
> @@ -5426,9 +5426,20 @@ rep_write_contents_close(void *baton)
>/* Check and see if we already have a representation somewhere that's
>   identical to the one we just wrote out. */
>if (ffd->rep_sharing_allowed)
> -/* ### TODO: ignore errors opening the DB (issue #3506) * */
> -SVN_ERR(svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
> - b->parent_pool));
> +{
> +  svn_error_t *err;
> +  err = svn_fs_fs__get_rep_reference(&old_rep, b->fs, rep->sha1_checksum,
> + b->parent_pool);
> +  if (err)
> +{
> +  /* Something's wrong with the rep-sharing index.  We can continue 
> + without rep-sharing, but warn.
> +   */
> +  (fs->warning)(fs->warning_baton, err);
> +  svn_error_clear(err);
> +  old_rep = NULL;
> +}
> +}
>else
>  old_rep = NULL;
>  

Committed the first hunk in r1051559; the second hunk is IMO unnecessary
once http://mid.gmane.org/4d0fab1a.3060...@orcaware.com is addressed.

> @@ -6377,12 +6388,22 @@ svn_fs_fs__commit(svn_revnum_t *new_rev_p,
>   SVN_ERR(svn_fs_fs__with_write_lock(fs, commit_body, &cb, pool));
>  
>if (ffd->rep_sharing_allowed)
>  {
> -  /* ### TODO: ignore errors opening the DB (issue #3506) * */
> -  SVN_ERR(svn_fs_fs__open_rep_cache(fs, pool));
> -  SVN_ERR(svn_sqlite__with_transaction(ffd->rep_cache_db,
> +  svn_error_t *err = SVN_NO_ERROR;
> +
> +  if (! err)
> +err = svn_fs_fs__open_rep_cache(fs, pool);
> +
> +  if (! err)
> +err = svn_sqlite__with_transaction(ffd->rep_cache_db,
> commit_sqlite_txn_callback,
> -   &cb, pool));
> +   &cb, pool);
> +
> +  if (err)
> +/* The opposite of svn_error_quick_wrap(): same error message,
> +   different error code. */
> +return svn_error_create(SVN_ERR_REPOS_POST_COMMIT_HOOK_FAILED, err,
> +/* TODO: svn_error_best_message() */ 
> (err)->message);
>  }
>  
>return SVN_NO_ERROR;
> ]]]
> 
> > Stefan

Re: An access permissions problem

[Stefan Sperling]

On Tue, Dec 21, 2010 at 12:28:29PM -0500, David Weintraub wrote:
> On Tue, Dec 21, 2010 at 10:59 AM, David Aldrich
>  wrote:
> > Thanks for your help. Yes, the branches, tags, and trunk directories are at 
> > the root. In your suggestion, I am worried that a developer might create a 
> > branch containing ConfidentialFolder in /branches rather than in 
> > /branches/ConfidentialBranches, by mistake. Do you agree that is a problem?
> 
> Sure, that's a possible issue. One of the biggest problems with
> Subversion is that it is almost impossible to delete any information
> from the repository. You put in confidential information in the wrong
> place, and you basically have to do a dump/filter/load to remove it
> from the repository.
> 
> To solve this issue, you can create a pre-commit hook that will
> prevent someone from copying the confidential information project to
> the plain /branches branch.
> 
> When a copy is done, svnlook will list where the copy is from, and
> your hook can intercept this information.
> 
> I don't think my kitchen-sink pre-commit hook can be configured to
> prevent this from happening. My script can prevent particular people
> from creating a tag or branch, but never looks at the "to"
> information.
> 
> You'll have to write your own hook script. Fortunately, it isn't too
> difficult -- especially since you're just checking for a very simple
> thing. Do you see an "A' transaction where the from is from the
> confidential directory and the "to" is to the branches directory? If
> so, fail the transaction.

It's better to fail if the copy is not going to the right place,
rather than going to one of many possible wrong places.

Regarding the external question: I think checkout and updates will fail if
the external cannot be accessed. It's quite easy to try this out on
a new repository created with svnadmin create:

 svnadmin create /tmp/myrepos
 svn co file:///tmp/myrepos working-copy
 cd working-copy
 svn mkdir dir

Now configure externals on "dir" that point to non-existing URLs,
run svn commit, and do more checkouts and updates see for yourself
what Subversion will do.

Stefan

RE: SVN BUG : Lines disappeared after update and check in

[Bob Archer]

> I experienced the following behavior with SVN. The steps i did are
> :
> 
> 1- I made changes in a file
> 2- updated the file
> 3- Checked in the file after the merge succeeded
> 4- In the resulting file 6 lines disappeared.
> 
> Is it considered as a bug?
> has anyone experienced such a behavior?
> 

If it truly is losing lines that would be a bug.

However, what were the merged in changes? Are you sure the merge during the 
update didn't remove lines?

BOb

Looking to hire Software Engineers to Help Develop Subversion

[David Richards]

[This is a one-off and we will not post this again on this list]

Following the 
announcementby
WANdisco yesterday that we would undertake the work to  fix / improve
branching and merging in Subversion; we are on the lookout for new
Subversion developers to complement our existing team. If you (or someone
you know) have what it takes feel free to email me or careers {a.t}
 WAndisco . com. We are looking to hire a large number of new developers.
Also, contact us if you would just like to donate some of your own time.

I would also say that this work will be completed both *for* and as *part of
* the *community*. I have tried to answer questions surrounding this on my
blog.
Any questions or concerns feel free to email me directly.


Highlights of the proposed improvements include:

   - Enhanced Subversion merge performance, with features such as allowing
   users to take all of the changes committed on one branch and replay them on
   another
   - Subversion rename tracking to eliminate tree conflicts during merges
   when file names change
   - Improve correctness of 'SVN blame - g' to make it possible to follow
   complete merge history and trace authors of merged code
   - Improve 'SVN import' to better manage branches.
   - Make Authz architecture more granular similar to Unix filesystem
   permissions.
   - Repository-dictated configuration.





--
Regards,

David Richards
President & CEO
WANdisco, Inc.

http://www.wandisco.com
http://blog.wandisco.com/david/



Free Online Subversion Training
http://svn.wandisco.com/eTraining

Join the Open Source Subversion Community
http://svn.wandisco.com/eCommunity

Read our blogs!
http://blogs.wandisco.com/

Follow us on Twitter
http://svn.wandisco.com/eTwitter

Join us on facebook!
http://svn.wandisco.com/eFacebook

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
 If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone.  Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized.  The views and opinions
expressed in this e-mail message are the author's own and may not reflect
the views and opinions of WANdisco, unless the author is authorized by
WANdisco to express such views or opinions on its behalf.  All email sent to
or from this address is subject to electronic storage and review by
WANdisco.  Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.

Re: SVN BUG : Lines disappeared after update and check in

[riad benmouhoub]

I did so and the lines are there!

Riad

On Tue, Dec 21, 2010 at 7:43 PM, Bob Archer  wrote:

> I would do a diff between the rev that you update to, and the one before
> that. See if lines were removed. 1.6.5 isn't that old.
>
> ( you should reply all so messages go to the list too.)
>
>
>
> BOb
>
>
>
>
>
> *From:* riad benmouhoub [mailto:riad.benmouh...@gmail.com]
> *Sent:* Tuesday, December 21, 2010 1:41 PM
> *To:* Bob Archer
> *Subject:* Re: SVN BUG : Lines disappeared after update and check in
>
>
>
> Hi Bob,
>
>
>
> Thanks for the quick answer.
>
>
>
> Well the thing is that I didn't perform a tkdiff after the update!!
>
>
>
> we are working with the following SVN version (I guess it is a bit old!):
>
> Subversion command-line client, version 1.6.5.
>
>
>
> I had this problem two times today after performing each time the same
> procedure i.e. update then check in
>
>
>
> Riad
>
> On Tue, Dec 21, 2010 at 7:22 PM, Bob Archer  wrote:
>
> > I experienced the following behavior with SVN. The steps i did are
> > :
> >
> > 1- I made changes in a file
> > 2- updated the file
> > 3- Checked in the file after the merge succeeded
> > 4- In the resulting file 6 lines disappeared.
> >
> > Is it considered as a bug?
> > has anyone experienced such a behavior?
> >
>
> If it truly is losing lines that would be a bug.
>
> However, what were the merged in changes? Are you sure the merge during the
> update didn't remove lines?
>
> BOb
>
>
>

Re: SVN BUG : Lines disappeared after update and check in

[Johan Corveleyn]

[ please don't top-post, i.e. put your reply at the bottom (or inline)
of the thing you're replying to. I reshuffled a bit below, to make the
ordering more logical for this list. ]

On Tue, Dec 21, 2010 at 7:55 PM, riad benmouhoub
 wrote:
>> On Tue, Dec 21, 2010 at 7:22 PM, Bob Archer  wrote:
>>
>> > I experienced the following behavior with SVN. The steps i did are
>> > :
>> >
>> > 1- I made changes in a file
>> > 2- updated the file
>> > 3- Checked in the file after the merge succeeded
>> > 4- In the resulting file 6 lines disappeared.
>> >
>> > Is it considered as a bug?
>> > has anyone experienced such a behavior?
>> >
>>
>> If it truly is losing lines that would be a bug.
>>
>> However, what were the merged in changes? Are you sure the merge during
>> the update didn't remove lines?
>>
>> BOb
>>
>>
>> From: riad benmouhoub [mailto:riad.benmouh...@gmail.com]
>> Sent: Tuesday, December 21, 2010 1:41 PM
>> To: Bob Archer
>> Subject: Re: SVN BUG : Lines disappeared after update and check in
>>
>>
>>
>> Hi Bob,
>>
>>
>>
>> Thanks for the quick answer.
>>
>>
>>
>> Well the thing is that I didn't perform a tkdiff after the update!!
>>
>>
>>
>> we are working with the following SVN version (I guess it is a bit old!):
>>
>> Subversion command-line client, version 1.6.5.
>>
>>
>>
>> I had this problem two times today after performing each time the same
>> procedure i.e. update then check in
>>
>>
>>
>> Riad
> On Tue, Dec 21, 2010 at 7:43 PM, Bob Archer  wrote:
>>
>> I would do a diff between the rev that you update to, and the one before
>> that. See if lines were removed. 1.6.5 isn't that old.
>>
>> ( you should reply all so messages go to the list too.)
>>
>>
>>
>> BOb
>
> I did so and the lines are there!
> Riad

I think you need to provide more details, before this can be confirmed
to be a bug. Can you describe precisely what svn commands you
executed? Maybe give a complete example, based on your experience
(feel free to replace file/directory names with dummy example stuff)?


Cheers,
-- 
Johan

Re: Looking to hire Software Engineers to Help Develop Subversion

[Pablo Beltran]

Hi,

I have no doubt about those all features will be good for the future of
Subversion, from a technical point of view.

On the other hand, the underlaying message scares me. The message is clear:
Apache can't drive the development process by itself and only Wandisco can
do it in the right way and in timing.

And I think that this exceeds Subversion project and undermines Apache's
authority.

Today is Wandisco and Subversion. Tomorrow could be Oracle or Microsoft
doing the same with other project. I would not like see Apache become in a
silly Software Factory.

But of course, I have not enough knowledge about how Apache internally works
and perhaps I'm saying a very great stupidness. So, my apologizes for that
if that is the case.

Pablo.

On Tue, Dec 21, 2010 at 7:38 PM, David Richards  wrote:

> [This is a one-off and we will not post this again on this list]
>
> Following the 
> announcementby 
> WANdisco yesterday that we would undertake the work to  fix / improve
> branching and merging in Subversion; we are on the lookout for new
> Subversion developers to complement our existing team. If you (or someone
> you know) have what it takes feel free to email me or careers {a.t}
>  WAndisco . com. We are looking to hire a large number of new developers.
> Also, contact us if you would just like to donate some of your own time.
>
> I would also say that this work will be completed both *for* and as *part
> of* the *community*. I have tried to answer questions surrounding this on
> my 
> blog.
> Any questions or concerns feel free to email me directly.
>
>
> Highlights of the proposed improvements include:
>
>- Enhanced Subversion merge performance, with features such as allowing
>users to take all of the changes committed on one branch and replay them on
>another
>- Subversion rename tracking to eliminate tree conflicts during merges
>when file names change
>- Improve correctness of 'SVN blame - g' to make it possible to follow
>complete merge history and trace authors of merged code
>- Improve 'SVN import' to better manage branches.
>- Make Authz architecture more granular similar to Unix filesystem
>permissions.
>- Repository-dictated configuration.
>
>
>
>
>
> --
> Regards,
>
> David Richards
> President & CEO
> WANdisco, Inc.
>
> http://www.wandisco.com
> http://blog.wandisco.com/david/
>
>
>
> Free Online Subversion Training
> http://svn.wandisco.com/eTraining
>
> Join the Open Source Subversion Community
> http://svn.wandisco.com/eCommunity
>
> Read our blogs!
> http://blogs.wandisco.com/
>
> Follow us on Twitter
> http://svn.wandisco.com/eTwitter
>
> Join us on facebook!
> http://svn.wandisco.com/eFacebook
>
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
> PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its
> subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
>  If you are not the intended recipient, please notify us immediately and
> destroy the message without disclosing its contents to anyone.  Any
> distribution, use or copying of this e-mail or the information it contains
> by other than an intended recipient is unauthorized.  The views and opinions
> expressed in this e-mail message are the author's own and may not reflect
> the views and opinions of WANdisco, unless the author is authorized by
> WANdisco to express such views or opinions on its behalf.  All email sent to
> or from this address is subject to electronic storage and review by
> WANdisco.  Although WANdisco operates anti-virus programs, it does not
> accept responsibility for any damage whatsoever caused by viruses being
> passed.
>

Re: Looking to hire Software Engineers to Help Develop Subversion

[David Weintraub]

On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran  wrote:
> Hi,
>
> I have no doubt about those all features will be good for the future of
> Subversion, from a technical point of view.
>
> On the other hand, the underlaying message scares me. The message is clear:
> Apache can't drive the development process by itself and only Wandisco can
> do it in the right way and in timing.
>
> And I think that this exceeds Subversion project and undermines Apache's
> authority.
>
> Today is Wandisco and Subversion. Tomorrow could be Oracle or Microsoft
> doing the same with other project. I would not like see Apache become in a
> silly Software Factory.
>
> But of course, I have not enough knowledge about how Apache internally works
> and perhaps I'm saying a very great stupidness. So, my apologizes for that
> if that is the case.
>

I am going to look at this a bit differently: Has IBM taken over
Linux? A majority of the changes in Linux are done by IBM paid
employees. IBM has its own goals and its own ideas about what they
want to do with Linux.

However, I believe most people feel that Linux isn't an IBM project
despite the massive amount of work done by a single company.
Basically, IBM benefits from Linux, so they do a lot of code work,
sometimes working on areas that have been previously neglected. The
better Linux is, the more IBM can sell Linux solutions.

Subversion has had a lot of problems since version 1.5 has come out.
Basically, the merge/branch tracking isn't that great. In fact, many
people prefer the 1.4 version which doesn't make any pretensions about
tracking branching and merging.

Meanwhile, many people feel Subversion is past its prime. Many open
source projects are moving from Subversion to Git. Actually, this
makes sense for open source projects, but it is beginning to affect
commercial applications. People are starting to push Git as a
commercial SCM package.

I recently pointed out on another list that I might recommend a piece
of software I don't think is as good as another piece of software
simply because the "inferior" product plays better with the other
software the company uses and because users are more familiar with it.

I might not like Git as a commercial version control system, but if
most developers are more familiar with Git than Subversion, and 3rd
party products start integrating with Git in better ways than they
integrate with Subversion, guess what I'm going to start to recommend.

So far, Subversion isn't being forked, and a fork would not be good
for WANdisco. They are heavily dependent upon people selecting
Subverson as a version control system. What they want to do is fix
some of the underlying issues Subversion has had for the last three
years and get the Subversion project to accept them. I can't see any
reason why the Subversion project would reject them. After all,
Subversion was once run by CollabNet which had commercial interests in
Subversion. Yet, no one complained about CollabNet "dominating" the
project.

I hope that WANdisco is able to fix many of the issues that have been
plaguing Subversion for years. I don't believe that those who are
leading Subversion have "failed", but that a private company
committing resources to an open source project can be a good thing.

-- 
David Weintraub
qazw...@gmail.com

Re: Looking to hire Software Engineers to Help Develop Subversion

[David Richards]

David,

Absolutely correct!

Your analysis / explanation is much better than my own. Thank you.

- David

On Tue, Dec 21, 2010 at 12:25 PM, David Weintraub  wrote:

> On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran  wrote:
> > Hi,
> >
> > I have no doubt about those all features will be good for the future of
> > Subversion, from a technical point of view.
> >
> > On the other hand, the underlaying message scares me. The message is
> clear:
> > Apache can't drive the development process by itself and only Wandisco
> can
> > do it in the right way and in timing.
> >
> > And I think that this exceeds Subversion project and undermines Apache's
> > authority.
> >
> > Today is Wandisco and Subversion. Tomorrow could be Oracle or Microsoft
> > doing the same with other project. I would not like see Apache become in
> a
> > silly Software Factory.
> >
> > But of course, I have not enough knowledge about how Apache internally
> works
> > and perhaps I'm saying a very great stupidness. So, my apologizes for
> that
> > if that is the case.
> >
>
> I am going to look at this a bit differently: Has IBM taken over
> Linux? A majority of the changes in Linux are done by IBM paid
> employees. IBM has its own goals and its own ideas about what they
> want to do with Linux.
>
> However, I believe most people feel that Linux isn't an IBM project
> despite the massive amount of work done by a single company.
> Basically, IBM benefits from Linux, so they do a lot of code work,
> sometimes working on areas that have been previously neglected. The
> better Linux is, the more IBM can sell Linux solutions.
>
> Subversion has had a lot of problems since version 1.5 has come out.
> Basically, the merge/branch tracking isn't that great. In fact, many
> people prefer the 1.4 version which doesn't make any pretensions about
> tracking branching and merging.
>
> Meanwhile, many people feel Subversion is past its prime. Many open
> source projects are moving from Subversion to Git. Actually, this
> makes sense for open source projects, but it is beginning to affect
> commercial applications. People are starting to push Git as a
> commercial SCM package.
>
> I recently pointed out on another list that I might recommend a piece
> of software I don't think is as good as another piece of software
> simply because the "inferior" product plays better with the other
> software the company uses and because users are more familiar with it.
>
> I might not like Git as a commercial version control system, but if
> most developers are more familiar with Git than Subversion, and 3rd
> party products start integrating with Git in better ways than they
> integrate with Subversion, guess what I'm going to start to recommend.
>
> So far, Subversion isn't being forked, and a fork would not be good
> for WANdisco. They are heavily dependent upon people selecting
> Subverson as a version control system. What they want to do is fix
> some of the underlying issues Subversion has had for the last three
> years and get the Subversion project to accept them. I can't see any
> reason why the Subversion project would reject them. After all,
> Subversion was once run by CollabNet which had commercial interests in
> Subversion. Yet, no one complained about CollabNet "dominating" the
> project.
>
> I hope that WANdisco is able to fix many of the issues that have been
> plaguing Subversion for years. I don't believe that those who are
> leading Subversion have "failed", but that a private company
> committing resources to an open source project can be a good thing.
>
> --
> David Weintraub
> qazw...@gmail.com
>

RE: Looking to hire Software Engineers to Help Develop Subversion

[Bob Archer]

> On Tue, Dec 21, 2010 at 12:25 PM, David Weintraub
>  wrote:
> On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran 
> wrote:
> > Hi,
> >
> > I have no doubt about those all features will be good for the
> future of
> > Subversion, from a technical point of view.
> >
> > On the other hand, the underlaying message scares me. The message
> is clear:
> > Apache can't drive the development process by itself and only
> Wandisco can
> > do it in the right way and in timing.
> >
> > And I think that this exceeds Subversion project and undermines
> Apache's
> > authority.
> >
> > Today is Wandisco and Subversion. Tomorrow could be Oracle or
> Microsoft
> > doing the same with other project. I would not like see Apache
> become in a
> > silly Software Factory.
> >
> > But of course, I have not enough knowledge about how Apache
> internally works
> > and perhaps I'm saying a very great stupidness. So, my apologizes
> for that
> > if that is the case.
> >
> 
> I am going to look at this a bit differently: Has IBM taken over
> Linux? A majority of the changes in Linux are done by IBM paid
> employees. IBM has its own goals and its own ideas about what they
> want to do with Linux.
> 
> However, I believe most people feel that Linux isn't an IBM project
> despite the massive amount of work done by a single company.
> Basically, IBM benefits from Linux, so they do a lot of code work,
> sometimes working on areas that have been previously neglected. The
> better Linux is, the more IBM can sell Linux solutions.
> 
> Subversion has had a lot of problems since version 1.5 has come
> out.
> Basically, the merge/branch tracking isn't that great. In fact,
> many
> people prefer the 1.4 version which doesn't make any pretensions
> about
> tracking branching and merging.
> 
> Meanwhile, many people feel Subversion is past its prime. Many open
> source projects are moving from Subversion to Git. Actually, this
> makes sense for open source projects, but it is beginning to affect
> commercial applications. People are starting to push Git as a
> commercial SCM package.
> 
> I recently pointed out on another list that I might recommend a
> piece
> of software I don't think is as good as another piece of software
> simply because the "inferior" product plays better with the other
> software the company uses and because users are more familiar with
> it.
> 
> I might not like Git as a commercial version control system, but if
> most developers are more familiar with Git than Subversion, and 3rd
> party products start integrating with Git in better ways than they
> integrate with Subversion, guess what I'm going to start to
> recommend.
> 
> So far, Subversion isn't being forked, and a fork would not be good
> for WANdisco. They are heavily dependent upon people selecting
> Subverson as a version control system. What they want to do is fix
> some of the underlying issues Subversion has had for the last three
> years and get the Subversion project to accept them. I can't see
> any
> reason why the Subversion project would reject them. After all,
> Subversion was once run by CollabNet which had commercial interests
> in
> Subversion. Yet, no one complained about CollabNet "dominating" the
> project.
> 
> I hope that WANdisco is able to fix many of the issues that have
> been
> plaguing Subversion for years. I don't believe that those who are
> leading Subversion have "failed", but that a private company
> committing resources to an open source project can be a good thing.

> Absolutely correct!
> 
> Your analysis / explanation is much better than my own. Thank you.
> 
> - David

I also think this is good news and look forward to seeing the WANDisco 
contributions to the project. And if I had any more knowledge of the svn 
internals I might be applying for one of those positions.

BOb

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Danny Trebbien]

> > Hi Danny,
> > I am working with Geir Engebakken on this and we understand you won't 
> > release
> > the patch now until 1.7.x - That's fine but I wanted to try out the patch 
> > myself
> > now so I tried to run it in and it is looking for sync.c and sync.h which 
> > dont
> > seem to exist in my source tree. I have downloaded the latest version 1.6.15
> > ??
> >
> > Any help is appreciated!!
> >
> > -Chris
>
> Resolved now, seems the sync.c file is added in the Subversion source trunk 
> (1.7?) , but is not not in any
> 1.6.x releases of the source, so that fooled us.
>
> Geir

Hi Chris and Geir,

My apologies for the belated response. I do not receive e-mails from
the Subversion Developers' or Subversion Users' lists unless I am
CC'ed directly.

I do not know if you saw

or not, but you may find it helpful.

Let me know if you have any other questions. Just be sure to click
"Reply to All" so that I will see it :)

Danny

Re: Revisions being involved while comparing branches

[Pablo Beltran]

Maybe the point is efficiency.

the *svn log -v*  output for a revision range could be represented by a
matrix with the revision numbers as rows and the changed paths as columns.

So, for each revision is easy inquire the revised paths. That is simple
because all the results are retrieved from one execution.

But, how does efficiently transpose the matrix? -> paths as rows and
revisions as columns? and do it for the same set of values?

For example, when two *tags* are compared with TortoiseSVN the result is a
list of revised paths. But revisions are missing from that view. That is
because TortoiseSVN dispalys the *svn diff -summarize* results. So, how to
display also the involved revisions for each path? The *svn info* displays
only the last revision and not all involved so you should execute the *svn
log* command for each revised path. And that is not efficient.

The goal is adding the involved revisions on the compare directories view of
TortoiseSVN and do it in the most efficient way.


On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf wrote:

> 'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies)
>
> 'dig the logs' is "lookup the copyfrom revisions of the tags, and run
> log on replay.c for that revision range".  What's wrong with that?
>
> Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100:
> > Is there a direct way (via cmd line) to find out the revisions involved
> in
> > the summary result of differencing two branches?
> >
> > An easy example:
> >
> >
> > 
> >
> > svn diff
> >
> http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos
> >
> http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize
> >
> > M
> >
> http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c
> >
> > 
> >
> > The two tags were created in r1036188 and r1038150, but the replay.c file
> > was modified  in
> >
> http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005
> >
> > Is there anyway to find out the 1037005 revision number without having to
> > analyze the logs?
>

Re: Looking to hire Software Engineers to Help Develop Subversion

[Johan Corveleyn]

On Tue, Dec 21, 2010 at 9:32 PM, David Richards  wrote:
> On Tue, Dec 21, 2010 at 12:25 PM, David Weintraub  wrote:
>>
>> On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran  wrote:
>> > Hi,
>> >
>> > I have no doubt about those all features will be good for the future of
>> > Subversion, from a technical point of view.
>> >
>> > On the other hand, the underlaying message scares me. The message is
>> > clear:
>> > Apache can't drive the development process by itself and only Wandisco
>> > can
>> > do it in the right way and in timing.
>> >
>> > And I think that this exceeds Subversion project and undermines Apache's
>> > authority.
>> >
>> > Today is Wandisco and Subversion. Tomorrow could be Oracle or Microsoft
>> > doing the same with other project. I would not like see Apache become in
>> > a
>> > silly Software Factory.
>> >
>> > But of course, I have not enough knowledge about how Apache internally
>> > works
>> > and perhaps I'm saying a very great stupidness. So, my apologizes for
>> > that
>> > if that is the case.
>> >
>>
>> I am going to look at this a bit differently: Has IBM taken over
>> Linux? A majority of the changes in Linux are done by IBM paid
>> employees. IBM has its own goals and its own ideas about what they
>> want to do with Linux.
>>
>> However, I believe most people feel that Linux isn't an IBM project
>> despite the massive amount of work done by a single company.
>> Basically, IBM benefits from Linux, so they do a lot of code work,
>> sometimes working on areas that have been previously neglected. The
>> better Linux is, the more IBM can sell Linux solutions.
>>
>> Subversion has had a lot of problems since version 1.5 has come out.
>> Basically, the merge/branch tracking isn't that great. In fact, many
>> people prefer the 1.4 version which doesn't make any pretensions about
>> tracking branching and merging.
>>
>> Meanwhile, many people feel Subversion is past its prime. Many open
>> source projects are moving from Subversion to Git. Actually, this
>> makes sense for open source projects, but it is beginning to affect
>> commercial applications. People are starting to push Git as a
>> commercial SCM package.
>>
>> I recently pointed out on another list that I might recommend a piece
>> of software I don't think is as good as another piece of software
>> simply because the "inferior" product plays better with the other
>> software the company uses and because users are more familiar with it.
>>
>> I might not like Git as a commercial version control system, but if
>> most developers are more familiar with Git than Subversion, and 3rd
>> party products start integrating with Git in better ways than they
>> integrate with Subversion, guess what I'm going to start to recommend.
>>
>> So far, Subversion isn't being forked, and a fork would not be good
>> for WANdisco. They are heavily dependent upon people selecting
>> Subverson as a version control system. What they want to do is fix
>> some of the underlying issues Subversion has had for the last three
>> years and get the Subversion project to accept them. I can't see any
>> reason why the Subversion project would reject them. After all,
>> Subversion was once run by CollabNet which had commercial interests in
>> Subversion. Yet, no one complained about CollabNet "dominating" the
>> project.
>>
>> I hope that WANdisco is able to fix many of the issues that have been
>> plaguing Subversion for years. I don't believe that those who are
>> leading Subversion have "failed", but that a private company
>> committing resources to an open source project can be a good thing.
>>
>> --
>> David Weintraub
>> qazw...@gmail.com
>
>
> David,
> Absolutely correct!
> Your analysis / explanation is much better than my own. Thank you.
> - David
>

I like the "call for action", and the intention to invest more in the
development of Subversion. However, I do not like the blog entry. I
may be overly sensitive to this kind of thing, but I'm rather
antagonized by the paragraph "Hang on a Minute! Didn’t the Community
Just Announce A Road Map?".

I can feel the frustration with the lack of progress (or translated
frustration of Wandisco's big customers). I understand this
frustration (I feel it too sometimes), and the desire to do something
about it (that's why I got involved myself). However, this paragraph
has an undertone of blaming it on lack of involvement/dedication by
the community and developers, and bad behavior by some developers.

This is not a good way to motivate the community positively to work
with you, it's a negative message. At least that's how it sounds to me
(admittedly, I may not have the full picture of all that's going on,
but so do probably most readers of the blog).

I'm specifically talking about the following sentences:

- In answer to the question "Didn't the community just announce a road
map?": "Yes they did, but that’s pretty much all that happened (and
that really pisses us off.) "

What? I'm subscribed to the dev-list and the

Re: Revisions being involved while comparing branches

[Daniel Shahaf]

Pablo Beltran wrote on Tue, Dec 21, 2010 at 23:29:23 +0100:
> Maybe the point is efficiency.
> 

OK.

> the *svn log -v*  output for a revision range could be represented by a
> matrix with the revision numbers as rows and the changed paths as columns.
> 
> So, for each revision is easy inquire the revised paths. That is simple
> because all the results are retrieved from one execution.
> 
> But, how does efficiently transpose the matrix? -> paths as rows and
> revisions as columns? and do it for the same set of values?
> 

In other words, how does one compute for a set of paths which revisions
touched each of the paths?

> For example, when two *tags* are compared with TortoiseSVN the result is a
> list of revised paths. But revisions are missing from that view. That is
> because TortoiseSVN dispalys the *svn diff -summarize* results. So, how to
> display also the involved revisions for each path? The *svn info* displays
> only the last revision and not all involved so you should execute the *svn
> log* command for each revised path. And that is not efficient.
> 

You could use the #2 syntax of 'svn log':

% $svn h log | head
log: Show the log messages for a set of revision(s) and/or path(s).
usage: 1. log [pat...@rev]
   2. log u...@rev] [PATH...]

I'm not sure offhand at what layer the looping on paths is implemented,
though; but I hope it's done server-side.

> The goal is adding the involved revisions on the compare directories view of
> TortoiseSVN and do it in the most efficient way.
> 

Solving the problem for the most general case of comparing any two
directories is a hard problem.

> 

HTH,

Daniel

> On Tue, Dec 21, 2010 at 12:21 PM, Daniel Shahaf 
> wrote:
> 
> > 'svn info' on the 1.6.15 file will tell you that. (thanks cheap copies)
> >
> > 'dig the logs' is "lookup the copyfrom revisions of the tags, and run
> > log on replay.c for that revision range".  What's wrong with that?
> >
> > Pablo Beltran wrote on Mon, Dec 20, 2010 at 19:22:20 +0100:
> > > Is there a direct way (via cmd line) to find out the revisions involved
> > in
> > > the summary result of differencing two branches?
> > >
> > > An easy example:
> > >
> > >
> > > 
> > >
> > > svn diff
> > >
> > http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos
> > >
> > http://svn.apache.org/repos/asf/subversion/tags/1.6.15/subversion/libsvn_repos--summarize
> > >
> > > M
> > >
> > http://svn.apache.org/repos/asf/subversion/tags/1.6.14/subversion/libsvn_repos/replay.c
> > >
> > > 
> > >
> > > The two tags were created in r1036188 and r1038150, but the replay.c file
> > > was modified  in
> > >
> > http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/libsvn_repos/repla...@1037005
> > >
> > > Is there anyway to find out the 1037005 revision number without having to
> > > analyze the logs?
> >

Re: A problem trying to use svn:// and http:// for a same repository at the same time

[David Xie]

Thanks Stefan.

Wow, it really works when disable authz. This means I could access to svn://
172.18.127.148/test (read and write) and successfully to view log
history. Hard to believe!
#authz-db = authz

And the logs are showed correctly without authz.

What's wrong? What should I do to make authz and log history both work?

Regards,
David

On Tue, Dec 21, 2010 at 5:17 PM, Stefan Sperling  wrote:

>  On Tue, Dec 21, 2010 at 04:25:55PM +0800, 谢带达 wrote:
> > Thank you Stefan.
> >
> > I start svnserve this way:
> >
> > /local/svnroot/repository/one/conf/svnserve.conf
> > [general]
> > anon-access =
> > auth-access = write
> > password-db = passwd
> > authz-db = authz
> > /local/svnroot/repository/one/conf/authz
> > [/]
> > test = rw
> > * =
> >
> > /local/svnroot/repository/one/conf/passwd
> > [users]
> > test = test
> >
> > And then I start svnserve with root account:
> > /local/svnroot/subversion/bin/svnserve -d --listen-host 172.18.127.148
> > --root /local/svnroot/repository
> >
> > Yes I could connet to :
> > svn://172.18.127.148/test
> > svn://172.18.127.148/one
> >
> > The problem is that it show "Item is not readble" when I try to show log
> via
> > TSVN.
> > The only difference between Repository one and Repository test is that
> the
> > former is created with --pre-1.5-compatible but the latter not.
> > 3 snaps are attached for your reference.
>
> I think this means that something is wrong with your authz configuration.
> Can you try to disable authz to see if it works without?
>
> Stefan
>

Re: Looking to hire Software Engineers to Help Develop Subversion

[David Richards]

Johan,

Firstly, thank you for caring about Subversion - we *do*, passionately.

1. The feeling of a lack of progress is not new and it's not just
"WANdisco's big customers" as you put it. I don't think I am blaming any
individual - it's just a fact of life as I said "*We are not happy with the
volume, speed or participation on the project right now*". This is not new -
it's been a criticism since 2007. In fact these [fundamental] requirements
have been around and published since then. What we are saying, in fact, is
that Subversion cannot live in a vacuum - there is no point in us
complaining about a lack of action. That will achieve *nothing* about from
wasting time. As I say at the outset "*We are not doing this for direct
commercial reasons. We are doing this to protect the future of Subversion.
We are doing this because we care. We are doing this because we need to. We
are doing this because it is the right thing to do.*"

2. On the question of the road-map / commit logs. Firstly WC-NG, httpv2 etc
were already in train and we were already working on those things. Julian
Foad, for example, one of our core developers was actually a long way into
obliterate but he *had* to switch over to 1.7. I therefore don't regard 1.7
as an issue with the road-map. There are more immediate issues that *must*
be tackled now, ideally in parallel associated with branching & merging.
 Developers are working hard but there simply aren't enough of us, for
whatever reason, *actively* working on the project right now. Not
a criticism - just a fact of life.

3. On the question about "answering questions on user lists". Note I did say
"*Blogging, or answering questions on user lists are important*" Active user
lists are a good measure of an open source project and so is commits. I have
already received several offers to help code and that is *very* much
appreciated.

4. "unscrupulous committers decide to commit trivial changes in large files
to simply get their stats up." I'm not going to go into that here but I
repeat that the best way to create open source developers is by hiring great
people who create wonderful source code. The core developers of Subversion,
in my experience, are amazing individuals who maintain and create the best
SCM product on the planet I am *not* repeat *not* criticizing or setting any
of you / them in a bad light. that will *never* happen.

Johan, I hope this set's the record straight. We knew that by doing this
that we would open ourselves up to criticism.
We have tried alternative paths to effect change on the project but we feel
that now it the time to act.

Feel free to contact me directly and I am more than happy to talk directly
with you.

- David


On Tue, Dec 21, 2010 at 3:53 PM, Johan Corveleyn  wrote:

> On Tue, Dec 21, 2010 at 9:32 PM, David Richards 
> wrote:
> > On Tue, Dec 21, 2010 at 12:25 PM, David Weintraub 
> wrote:
> >>
> >> On Tue, Dec 21, 2010 at 3:03 PM, Pablo Beltran 
> wrote:
> >> > Hi,
> >> >
> >> > I have no doubt about those all features will be good for the future
> of
> >> > Subversion, from a technical point of view.
> >> >
> >> > On the other hand, the underlaying message scares me. The message is
> >> > clear:
> >> > Apache can't drive the development process by itself and only Wandisco
> >> > can
> >> > do it in the right way and in timing.
> >> >
> >> > And I think that this exceeds Subversion project and undermines
> Apache's
> >> > authority.
> >> >
> >> > Today is Wandisco and Subversion. Tomorrow could be Oracle or
> Microsoft
> >> > doing the same with other project. I would not like see Apache become
> in
> >> > a
> >> > silly Software Factory.
> >> >
> >> > But of course, I have not enough knowledge about how Apache internally
> >> > works
> >> > and perhaps I'm saying a very great stupidness. So, my apologizes for
> >> > that
> >> > if that is the case.
> >> >
> >>
> >> I am going to look at this a bit differently: Has IBM taken over
> >> Linux? A majority of the changes in Linux are done by IBM paid
> >> employees. IBM has its own goals and its own ideas about what they
> >> want to do with Linux.
> >>
> >> However, I believe most people feel that Linux isn't an IBM project
> >> despite the massive amount of work done by a single company.
> >> Basically, IBM benefits from Linux, so they do a lot of code work,
> >> sometimes working on areas that have been previously neglected. The
> >> better Linux is, the more IBM can sell Linux solutions.
> >>
> >> Subversion has had a lot of problems since version 1.5 has come out.
> >> Basically, the merge/branch tracking isn't that great. In fact, many
> >> people prefer the 1.4 version which doesn't make any pretensions about
> >> tracking branching and merging.
> >>
> >> Meanwhile, many people feel Subversion is past its prime. Many open
> >> source projects are moving from Subversion to Git. Actually, this
> >> makes sense for open source projects, but it is beginning to affect
> >> commercial applications. People are

RE: newbie doubt.. problem with import in windows

[Edward Ned Harvey]

> From: sajan [mailto:sajanjos...@gmail.com]
> Sent: Tuesday, December 21, 2010 3:58 AM
> 
> > URLs always have forward slashes. Try something like:
> >  svn import myproject file:///C:/code/svnrepo/myproject
> >
> thanks Stefan,
> sajan

Next time, I suggest making a subject which is more suggestive of the
subject you're actually talking about.  I guess just drop "newbie doubt"
from the existing subject.  Subversion is a pretty enormously deployed,
pretty widely supported application...  Any problems you encounter almost
certainly have logical explanation if you only need to have more intimate
knowledge.  In other words, in the future, assume it's working as designed,
and if you don't get what you expect, then assume you're expecting something
which isn't designed.

Svn works fine on windows and linux, OSX, and many other platforms alike.
There are some differences, but nothing as dramatic as "it's broken in
windows, can't import" etc.

Re: An access permissions problem

[Nico Kadel-Garcia]

On Tue, Dec 21, 2010 at 9:46 AM, David Aldrich  wrote:
> Hi
>
>
>
> We host each of our  projects in a separate svn repo and control access
> permissions via Apache.

Put the confidential materials in a separate repository. Use
svn:externals to access that separate, more securely managed
repository inside of working copies. This eliminates the ability to
"svn copy" the material inside the unsecured repository, but that
sounds acceptable.

It makes managing them on the client end a bit trickier, but it is
much more stable on the server side than trying to repeatedly pick and
choose the configuration of your Apache, authz, pre-commit, or other
tools.