MailBucket: subversion-users

Checksum error during commit

Wed, 14 May 2008 15:28:39 -0700

I did a merge followed by a commit and ran into this error . Never seen
this one before

Any clues folks?


==>>
..svn: Commit failed (details follow):
svn: Checksum mismatch for '/data/users/joe/www-dxx/lib/gtern/
cachearchiver/regenerators/.svn/text-base/arps.php.svn-base';
expected '7df4b3bee06e2830e463e9df00849c01', actual:
'dc28016c21fa849f25de873b06799864'

==>

Cheers
murli


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Compression?

Wed, 14 May 2008 17:01:05 -0400

>>>>> "Holger" == Holger Schulz  writes:

 Holger> Is there any compression active? I have a repository of 200
 Holger> MB, a dump of that repository is about 270 MB. A working copy
 Holger> has mor than 500 MB?

 Holger> How save is my data within that repository?

How many revisions?

I don't know about compression, but a working copy contains two copies
of every file -- the one you see and change, and the hidden one that
is used for diff and revert and the like.  So if you don't have a
whole lot of revisions, a working copy larger than the repository is
perfectly normal.

	  paul


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Version Control with Subversion - release date

Wed, 14 May 2008 15:50:01 -0400

When does the 'Version Control with Subversion' print version book come out?
It's been listed on Amazon.com as "pre order" for a while now.

Thanks,
Mike

Re: A special use-case using subversion

Wed, 14 May 2008 19:38:13 +0200

On Wed, May 14, 2008 at 12:23:28PM -0400, Andy Levy wrote:
> On Wed, May 14, 2008 at 5:55 AM, Ilyes Gouta  wrote:
> > Hi,
> >
> >> Why would you need to create a new branch for every sync?
> >
> > This is how it's explained in the vendor branches paragraph, in the
> > SVN book. As far as I know, we can't update a branch with the
> > revisions coming from another SVN repository. We can import it as a
> > new code, in a new branch, (and then merge it back in the said
> > long-living branch?). Am I right?
> 
> You could also use svn_load_dirs.pl to "import" the latest version,
> with all the adds/deletes/updates since the previous version.

Exactly, with this you only create the vendor branch once.

Ilyes, the basic idea is this:
When updating to a new version of the vendor's code, you check
out the vendor branch, which contains a previous version of the
vendor's code, into a working copy. Then you make that working
copy match the new version of the vendor's code -- this is the part
that should be automated better than it currently is.
Then you commit from the updated working copy to the vendor branch.
Now the vendor branch carries the new upstream version, and you can
merge from it into your own branches (and trunk).

So no, you really don't recreate the vendor branch every time you
do a sync to the vendor's most recent code. You just checkout the
vendor branch, make that working copy match the new version,
and then you commit.

To automate the updating process, we currently only have svn_load_dirs.pl,
piston (http://piston.rubyforge.org/) and similar wrapper solutions.
But they all use the same basic idea explained above.

Stefan

Merging two repositories

Wed, 14 May 2008 11:36:20 -0600

Hi,

Is there any way to merge two repositories and maintain the history of
both?

Thanks,=20
Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: How to relocate source repos for svnsync?

Wed, 14 May 2008 12:20:42 -0500

I don't think there is a way to do this.  We recently ran into the same =
issue as the domain name changed.  The only solution we had was to start =
over.

A way to keep everything from breaking if your old URL/repository is still =
working is to create a new repository with a different name.  Go through =
the steps of initialization and synchronization on the new repository.  =
Once the new repository is synchronized with HEAD on the master, remove/ren=
ame the old repository and then rename the new repository with the old =
repository's name.  This should keep the down time to a near minimum.

Hope this helps,

Johnathan

>>> On Wed, May 14, 2008 at 10:59 AM, in message , Liu
Yubao  wrote:=20
> Hi,
>=20
> I have setuped a repos B to sync from repos A with svnsync:
>=20
>    svnsync init file:///path/to/reposB   http://hostA/reposA
>    svnsync sync file:///path/to/reposB
>=20
> Now I add SSL support to the Apache server on hostA, the
> svnsync's SRCURL is changed to https://hostA/reposA, only the
> procotol changed, how can I relocate the source repos for svnsync?
>=20
> I have tried to do `svn pe svn:sync-from-url --revprop -r 0 \
> file://path/to/reposB` to change the source url, but `svnsync sync`
> tells me "svnsync: Malformed URL for repository".
>=20
> (I haven't subscribed this mail list, please CC to me, thanks!)
>=20
>=20
> Best regards,
>=20
> Liu Yubao
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: A special use-case using subversion

Wed, 14 May 2008 12:15:02 -0500

John Peacock wrote:
> Ilyes Gouta wrote:
>> But I'm still a bit worried by the merge details. SVK seems to be
>> exactly what we need, but as a package it doesn't have the visibility
>> other VCSs have...
> 
> FWIW, SVK handles vendor branches without breaking a sweat.  In fact, I 
> have mirrors of multiple different projects that I have occasion to work 
> on (including Subversion itself) and updating my local branch is usually 
> as simple as:
> 
>     $ svk pull
> 
> (from within a working copy of my local branch).  This retrieves all of 
> the updates from the mirror, commits it to the local mirror, then merges 
> those changes to the local branch.  If there is a conflict during the 
> merge (which is always possible), I've got SVK set to popup a graphical 
> merge editor (kdiff3 or meld), so it hardly takes any time at all.
> 
> The one caveat I will mention is that if someone renames a file and 
> changes it in a single commit in Subversion, then SVK can get confused 
> when trying to merge to the local branch.  To resolve this, I merely 
> have to perform the rename in my local branch and commit it.  After 
> that, the merge from upstream can proceed automatically.
> 
> Plus, the SVK repository is an ordinary Subversion repository, so 
> technically you can host that internally using normal Subversion 
> server/clients (be sure to never commit directly to the mirrored paths 
> though).

Speaking of 'less visible' packages... Has anyone looked at pushmi? I 
happened to notice the session mentioned in the upcoming OSCON 
(http://en.oreilly.com/oscon2008/public/schedule/detail/2505) but 
otherwise I don't see much publicity.  Is it like SVK with more 
attention to being able to use the replicated repository directly?

-- 
   Les Mikesell
    lesmikesell@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: A special use-case using subversion

Wed, 14 May 2008 12:37:40 -0400

Ilyes Gouta wrote:
> But I'm still a bit worried by the merge details. SVK seems to be
> exactly what we need, but as a package it doesn't have the visibility
> other VCSs have...

FWIW, SVK handles vendor branches without breaking a sweat.  In fact, I 
have mirrors of multiple different projects that I have occasion to work 
on (including Subversion itself) and updating my local branch is usually 
as simple as:

	$ svk pull

(from within a working copy of my local branch).  This retrieves all of 
the updates from the mirror, commits it to the local mirror, then merges 
those changes to the local branch.  If there is a conflict during the 
merge (which is always possible), I've got SVK set to popup a graphical 
merge editor (kdiff3 or meld), so it hardly takes any time at all.

The one caveat I will mention is that if someone renames a file and 
changes it in a single commit in Subversion, then SVK can get confused 
when trying to merge to the local branch.  To resolve this, I merely 
have to perform the rename in my local branch and commit it.  After 
that, the merge from upstream can proceed automatically.

Plus, the SVK repository is an ordinary Subversion repository, so 
technically you can host that internally using normal Subversion 
server/clients (be sure to never commit directly to the mirrored paths 
though).

John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

One Repo, Multiple projects, diferent passwords

Wed, 14 May 2008 07:19:20 -0700 (PDT)

Hello!

I want to know if i can have in one repository more than one project and with diferent user/pass for each project.

Now i am creating one repository per project in order to have diferent users/passwords but i have to run the svnserv with listeners in diferent ports for each one.

Thanks in advance!
Regards,
Fernando



      Tarjeta de crÃ©dito Yahoo! de Banco Supervielle.
SolicitÃ¡ tu nueva Tarjeta de crÃ©dito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar

Re: A special use-case using subversion

Wed, 14 May 2008 12:23:28 -0400

On Wed, May 14, 2008 at 5:55 AM, Ilyes Gouta  wrote:
> Hi,
>
>> Why would you need to create a new branch for every sync?
>
> This is how it's explained in the vendor branches paragraph, in the
> SVN book. As far as I know, we can't update a branch with the
> revisions coming from another SVN repository. We can import it as a
> new code, in a new branch, (and then merge it back in the said
> long-living branch?). Am I right?

You could also use svn_load_dirs.pl to "import" the latest version,
with all the adds/deletes/updates since the previous version.

> Thank you Stephan for your valuable comments!
>
> BR,
> Ilyes Gouta.
>
>> The idea is to have a single long-living branch receiving all
>> changes from upstream serially, in the same way as upstream applied
>> them. And from that you merge into your branches to get upstream
>> changes into your code.
>
>>> Both Mercurial and git are tempting, these are distributed VCSs and at
>>> some degrees offer SVN mirroring/tracking support. But I'm still a bit
>>> worried by the merge details. SVK seems to be exactly what we need,
>>> but as a package it doesn't have the visibility other VCSs have...
>>
>> As Tom Widmer pointed out, the distributed VCSs have the advantage of making
>> it easier to sync with upstream. I'm very much interested in evaluating
>> the quality of syncs done between Subversion repositories via git, as
>> Tom suggested. I wonder if it's really lossless, and how certain types
>> of conflicts are handled.
>>
>>> Any further comments guys? Thank you again for your help.
>>
>> Tom convinced me that Subversion certainly needs a way to make this
>> easier, at least for the inter-Subversion-repository use case.
>>
>> I faintly remember talk about an augmented diff format, which would
>> mirror svn operations like copy and move that aren't expressible
>> in unidiff. No idea what came out of that effort, but it certainly
>> sounds like it would help a lot to maintain vendor branches in cases
>> where the upstream source is also using Subversion. Of course, this
>> is nothing but vapourware and won't help you solve your problem right now.
>>
>> Inter-repository merges are also possible with 1.5, but are quite
>> primitive, meaning they don't do that much more than diff+patch.
>>
>> Note that the many wrapper solutions around svn that have
>> been suggested in this thread are very, very valuable in providing
>> requirements and ideas for an internal implementation in Subversion
>> for this kind of functionality. So if you use any of those, and provide
>> feedback about them to us, it would certainly help a tiny bit -- but until
>> someone steps up and starts a serious coding effort, you'll still be
>> dependent on the wrapper solution. Which may work well for you or not,
>> that's up to you to decide.
>>
>> Stefan
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

How to relocate source repos for svnsync?

Wed, 14 May 2008 23:59:00 +0800

Hi,

I have setuped a repos B to sync from repos A with svnsync:

   svnsync init file:///path/to/reposB   http://hostA/reposA
   svnsync sync file:///path/to/reposB

Now I add SSL support to the Apache server on hostA, the
svnsync's SRCURL is changed to https://hostA/reposA, only the
procotol changed, how can I relocate the source repos for svnsync?

I have tried to do `svn pe svn:sync-from-url --revprop -r 0 \
file://path/to/reposB` to change the source url, but `svnsync sync`
tells me "svnsync: Malformed URL for repository".

(I haven't subscribed this mail list, please CC to me, thanks!)


Best regards,

Liu Yubao

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: [BUG] Commit places working copy into bad state

Wed, 14 May 2008 09:37:15 -0500

On Wed, May 14, 2008 at 3:41 AM, Karl Fogel  wrote:
> Yep, there's a bug here.  Could you file an issue for it, so we don't
> lose track, pointing back to your original mail?

Thanks, Karl.  I have filed an issue for the bug.
http://subversion.tigris.org/issues/show_bug.cgi?id=3198

I filed it as P1 because I could not determine a workaround in 1.5.0
rc5.  Plus, I can see the potential for data loss if there are other
modified files in your working copy.  The only way to retain those
changes (including svn cp, svn mv, etc) is to perform a new checkout
and then make every change again manually which could potentially be
very hard to do if there are a lot of modified files.  If you think it
isn't that serious please let me know and I can drop it down to P3.

Would you like me to also repost this to the dev mailing list? Or
would you rather just leave it here and in the issue tracker?

Thank you,
Sebastian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: A special use-case using subversion

Wed, 14 May 2008 11:55:28 +0200

Hi,

> Why would you need to create a new branch for every sync?

This is how it's explained in the vendor branches paragraph, in the
SVN book. As far as I know, we can't update a branch with the
revisions coming from another SVN repository. We can import it as a
new code, in a new branch, (and then merge it back in the said
long-living branch?). Am I right?

Thank you Stephan for your valuable comments!

BR,
Ilyes Gouta.

> The idea is to have a single long-living branch receiving all
> changes from upstream serially, in the same way as upstream applied
> them. And from that you merge into your branches to get upstream
> changes into your code.

>> Both Mercurial and git are tempting, these are distributed VCSs and at
>> some degrees offer SVN mirroring/tracking support. But I'm still a bit
>> worried by the merge details. SVK seems to be exactly what we need,
>> but as a package it doesn't have the visibility other VCSs have...
>
> As Tom Widmer pointed out, the distributed VCSs have the advantage of making
> it easier to sync with upstream. I'm very much interested in evaluating
> the quality of syncs done between Subversion repositories via git, as
> Tom suggested. I wonder if it's really lossless, and how certain types
> of conflicts are handled.
>
>> Any further comments guys? Thank you again for your help.
>
> Tom convinced me that Subversion certainly needs a way to make this
> easier, at least for the inter-Subversion-repository use case.
>
> I faintly remember talk about an augmented diff format, which would
> mirror svn operations like copy and move that aren't expressible
> in unidiff. No idea what came out of that effort, but it certainly
> sounds like it would help a lot to maintain vendor branches in cases
> where the upstream source is also using Subversion. Of course, this
> is nothing but vapourware and won't help you solve your problem right now.
>
> Inter-repository merges are also possible with 1.5, but are quite
> primitive, meaning they don't do that much more than diff+patch.
>
> Note that the many wrapper solutions around svn that have
> been suggested in this thread are very, very valuable in providing
> requirements and ideas for an internal implementation in Subversion
> for this kind of functionality. So if you use any of those, and provide
> feedback about them to us, it would certainly help a tiny bit -- but until
> someone steps up and starts a serious coding effort, you'll still be
> dependent on the wrapper solution. Which may work well for you or not,
> that's up to you to decide.
>
> Stefan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

committing properties across externals

Wed, 14 May 2008 15:03:15 +0200

Hello! I'm new to this list.

In a post dated Feb 16, 2005 by Mark Zieg  , I can read:

    "if you want to commit changes that you've made in one or more of
    those external working copies, you must run svn commit explicitly on
    those working copies -- committing on the primary working copy will
    not recurse into any external ones"

Has this feature been improved since? Is it possible to "chain" the 
external working copies so that committing on one triggers a commit on 
each of them?

I could find in the documentation that using the "svn:externals" 
property allows to "chain" such external working copies together for 
checking out. But it does not seem to work for committing, unfortunately...

Regards,

Luc.

RE: VSS emulation

Wed, 14 May 2008 09:35:36 -0400

First, try to send posts to this list in ASCII.  Outlook makes it hard
for people like me to reply to non-ascii messages in anything but
top-post format.   
 
It sounds like you want an SCC plugin for Visual Studio and/or other SCC
complient IDEs.  There are a few out there, like these I got from a
quick google:
 
http://www.pushok.com/soft_svn.php
http://www.daveswebsite.com/software/tamtamsvn/index.shtml
http://tortoisesvnscc.tigris.org/
http://aigenta.com/products/UnifiedScc.aspx
This one lists several including VisualSVN:
http://www.subversionary.org/category/1/12/4

Also, take a look at ankh.  It doesn't use SCC, and from my personal
experience I like it better because there is no invasive SCC clutter
embedded in your project files:  http://ankhsvn.open.collab.net/
 .  It does, however, have some quirks
that some might not want to accept.
 
--
David

________________________________

	From: Furlan Bojan [mailto:furlan@iskratel.si] 
	Sent: Wednesday, May 14, 2008 8:44 AM
	To: users@subversion.tigris.org
	Subject: VSS emulation
	
	

	I know my question may sound stupid to some, but is there a tool
that would enable SVN to act as VSS, at least for IDE integrations? As
far as I know there is a 'standard'  that defines functionalities a tool
must provide to integrate with IDEs which integrate to VSS.

	We are using a tool that is not common and can be integrated to
VSS, but no other SCM tools, and we're forced to use VSS instead of SVN,
which is in use in other development areas.

	If this is not a question for this mailing list, please let me
know wheer to post it.

	 

	Regards

	Bojan Furlan



*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

Re: VSS emulation

Wed, 14 May 2008 07:10:49 -0700 (PDT)

--- On Wed, 5/14/08, Furlan Bojan  wrote:

I know my question may sound stupid to some, but is there a
tool that would enable SVN to act as VSS, at least for IDE integrations? As far
as I know there is a 'standard'  that defines functionalities a tool must
provide to integrate with IDEs which integrate to VSS. 

We are using a tool that is not common and can be integrated
to VSS, but no other SCM tools, and we're forced to use VSS instead of SVN,
which is in use in other development areas. 

If this is not a question for this mailing list, please let
me know wheer to post it. 

   

Regards 

Bojan Furlan

============================================

As far as IDE integration is concerned, I know of one such tool (not free though) "SVN SCC Proxy" which lets you use SVN with any Microsoft SCC enabled IDE. (the tool you are using is most probably connecting to VSS through MS SCC api which means, this proxy tool may work for you).

http://www.pushok.com/soft_svn.php

I have not tried it but you can see if it works for you.

Regards,
Waqas Arshed


 




      

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

problem in svn configuration

Wed, 14 May 2008 18:42:19 +0530

Hi Friends,

I am swamy, I am new to linux, I have a one problem when configuring the
subversion in apache, I installed apache-2.2.8.tar.gz,installed the
subversion and mod_dav_svn using the yum command.whenever I configured
the httpd.conf and start the apache i got error, error was "httpd:
Syntax error on line 54 of /usr/local/apache2/conf/httpd.conf: Cannot
load /usr/local/apache2/modules/mod_dav_svn.so into
server: /usr/lib/libsvn_fs_base-1.so.0: undefined symbol: db_create".I
do not know how to slove this problem ,if any one know please mail to
me.It is very urgent.

Thanks and Regards

swamy. 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

VSS emulation

Wed, 14 May 2008 14:43:53 +0200

I know my question may sound stupid to some, but is there a tool that
would enable SVN to act as VSS, at least for IDE integrations? As far as
I know there is a 'standard'  that defines functionalities a tool must
provide to integrate with IDEs which integrate to VSS.

We are using a tool that is not common and can be integrated to VSS, but
no other SCM tools, and we're forced to use VSS instead of SVN, which is
in use in other development areas.

If this is not a question for this mailing list, please let me know
wheer to post it.

 

Regards

Bojan Furlan

Re: A special use-case using subversion

Wed, 14 May 2008 10:59:33 +0200

On Wed, May 14, 2008 at 09:41:46AM +0200, Ilyes Gouta wrote:
> Hi all,
> 
> Thanks Benjamin for  your input. Actually I've been comparing, for a
> while now and keeping in mind my requirements, between a pure SVN
> approach, SVK, git-svn and hgsvn.
> 
> I don't really like the vendor branches concept since the upstream SVN
> repository (the trunk more specifically) is changing on a daily basis.
> It seems there will be a lot of effort synchronizing between the
> upstream repo. and our local mirror, i.e creating a new branch for
> every change, regenerating the meta-data, merging it with our trunk,
> etc.

Why would you need to create a new branch for every sync?
The idea is to have a single long-living branch receiving all
changes from upstream serially, in the same way as upstream applied
them. And from that you merge into your branches to get upstream
changes into your code.

> Both Mercurial and git are tempting, these are distributed VCSs and at
> some degrees offer SVN mirroring/tracking support. But I'm still a bit
> worried by the merge details. SVK seems to be exactly what we need,
> but as a package it doesn't have the visibility other VCSs have...

As Tom Widmer pointed out, the distributed VCSs have the advantage of making
it easier to sync with upstream. I'm very much interested in evaluating
the quality of syncs done between Subversion repositories via git, as
Tom suggested. I wonder if it's really lossless, and how certain types
of conflicts are handled.

> Any further comments guys? Thank you again for your help.

Tom convinced me that Subversion certainly needs a way to make this
easier, at least for the inter-Subversion-repository use case.

I faintly remember talk about an augmented diff format, which would
mirror svn operations like copy and move that aren't expressible
in unidiff. No idea what came out of that effort, but it certainly
sounds like it would help a lot to maintain vendor branches in cases
where the upstream source is also using Subversion. Of course, this
is nothing but vapourware and won't help you solve your problem right now.

Inter-repository merges are also possible with 1.5, but are quite
primitive, meaning they don't do that much more than diff+patch.

Note that the many wrapper solutions around svn that have
been suggested in this thread are very, very valuable in providing
requirements and ideas for an internal implementation in Subversion
for this kind of functionality. So if you use any of those, and provide
feedback about them to us, it would certainly help a tiny bit -- but until
someone steps up and starts a serious coding effort, you'll still be
dependent on the wrapper solution. Which may work well for you or not,
that's up to you to decide.

Stefan

Re: [BUG] Commit places working copy into bad state

Wed, 14 May 2008 04:41:27 -0400

"Sebastian Celis"  writes:
> As you can see, in this situation 'svn cleanup' complains about just
> b.txt instead of the file under .svn.  This led me down a path which
> eventually fixed my working copy, even though it wasn't pretty.
>
> Am I right in thinking that there are one or two bugs here?  I
> understand that I should have run 'svn revert b.txt' instead of 'rm
> b.txt'.  However, I still feel that my mistake shouldn't have caused
> the trouble that it did.

Yep, there's a bug here.  Could you file an issue for it, so we don't
lose track, pointing back to your original mail?

Thank you,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org