Re: --trust-server-cert

[Arpad Ilia]

Thank you for the thorough answer, I appriciate it.

Arpad Ilia

On Wednesday, June 09, 2010 07:03:21 pm Daniel Shahaf wrote:
> Short version: --trust-server-cert bypasses ONLY the "CA is unknown"
> check; it doesn't bypass hostname and expiry checks.
> 
> Arpad Ilia wrote on Wed, 9 Jun 2010 at 15:38 -:
> > Hi!
> > 
> > Is my observation correct that this command line switch
> > (--trust-server-cert) will not accept certificates where the
> > certificate hostname does not match?
> 
> To my surprise, yes.  (I tested with
> .)
> 
> Looking at the source code (from subversion/libsvn_subr/cmdline.c), we
> see this documentary comment:
> [[[
>Don't actually prompt.  Instead, set *CRED_P to valid credentials
>iff FAILURES is empty or is exactly SVN_AUTH_SSL_UNKNOWNCA.  If
>there are any other failure bits, then set *CRED_P to null (that
>is, reject the cert).
> ]]]
> 
> Where the possible bits are (from svn_auth.h):
> [[[
> /** Certificate is not yet valid. */
> #define SVN_AUTH_SSL_NOTYETVALID 0x0001
> 
> /** Certificate has expired. */
> #define SVN_AUTH_SSL_EXPIRED 0x0002
> 
> /** Certificate's CN (hostname) does not match the remote hostname. */
> #define SVN_AUTH_SSL_CNMISMATCH  0x0004
> 
> /** @brief Certificate authority is unknown (i.e. not trusted) */
> #define SVN_AUTH_SSL_UNKNOWNCA   0x0008
> 
> /** @brief Other failure. This can happen if neon has introduced a new
>  * failure bit that we do not handle yet. */
> #define SVN_AUTH_SSL_OTHER   0x4000
> ]]]
> 
> So, yes, current --trust-server-cert doesn't bypass the hostname and
> expiry checks.  I can see an argument for allowing
> a --I-know-what-I'm-doing-just-accept-that-cert-whatever-it-is mode,
> though.  (In case of an attack, the hostname and expiry are the easiest
> things to get right --- the CA is the hard part --- so if we allow
> bypassing *that*...)
> 
> > Thanks,
> > Arpad Ilia


signature.asc
Description: This is a digitally signed message part.

Re: merge and branch questions

[Arpad Ilia]

You can use 'svn merge' to merge changesets from the branch back into the 
trunk. You can also use reintegrate and still keep the branch, though it is not 
a very good idea since later trunk->branch 
synchronizations will cause lots of conflicts, as svn will try to merge the 
reintegration changeset into the branch. However this can be circumvented by 
doing a property merge (--record-only) for that 
changeset toward the branch and then doing the trunk -> branch sycnhronization 
as usual.

Nevertheless, I would recommend creating a new branch after every reintegrate 
as the book says.

Arpad Ilia

On Thursday, June 10, 2010 03:58:06 am Ralf Haring wrote:
> Hi, I am relatively new to svn and had some questions about
> maintaining branches and merging them back to the trunk.
> 
> The way my env is set up right now, ongoing development is done on the
> trunk. We have branches corresponding to various releases along the
> way. When needing to make a fix to an existing version, we've been
> pretty bad about making the change on the trunk instead of on the
> corresponding branch. We've in effect been treating the branches as
> snapshots at the time of release only.
> 
> This kind of defeats one purpose of having the branches so we want to
> do it right. I read the chapters at
> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html
> and http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html
> and want to see if I understand it properly. If I have a branch of the
> latest release version, it seems that I cannot use the normal svn
> merge to bring the change back into the trunk. As I understand it, svn
> merge is for merging things into *branches*. To merge things back into
> the trunk you would use the merge reintegrate option, but the branch
> should not be used for future work thereafter. So how can I
> periodically merge small fixes for the latest release back into the
> development trunk?
> 
> I understand the use case of creating a branch for work on a specific
> feature, keeping it up to date with normal dev changes as work on the
> feature progresses, and finally udpating the trunk and ending the
> branch. The workflow as outlined in the book fits that to a T, but it
> doesn't seem to work so well for needing to keep a branch around for a
> while and needing to do periodic merges to the trunk.
> 
> -Ralf


signature.asc
Description: This is a digitally signed message part.

Re: Two svn/apache servers accessing one database

[Ryan Schmidt]

On Jun 10, 2010, at 01:13, Stephen Connolly wrote:

> Why not just have the old server issue a 301/302 to the new server location 
> (I can never remember which is moved permanently)?

Subversion clients do not follow redirects.

Functionality change request for revision compare

[K F]

I was comparing two tags and if I select the older revision first 
it correctly shows a folder and the files under it as added. If I
 select the newer one first it shows the same directory as 
deleted but does not show the files under it as deleted. Is 
there a reason why it could not show the files under it as 
deleted? By not
 showing the files there is no reference to them as being a 
difference between the tags. It does the same thing if you just 
check between revisions.

Thanks,
Rich



  

startup questions

[Birdsell, John - OIG]

Hello,

 

I am new to svn, and have inherited the project of installing and
implementing version control.  Currently we are not using any form of
version control

 

A little background; our current environment set up is, develop on local
machines (win) ftp to test (Unix) on approval, ftp from local to
production (Unix) and we developing in ColdFusion.   The versioning
project was started about 6 months ago and the two people on the
project, a dba and a developer both left a month into it and of course
left no documentation as to their progress.

 

I currently have svn v.1.6.6 installed on our test box.

I have read:  svnbook.red-bean.com for 1.6 and "Pragmatic Version
Control using Subversion 2nd ed." And I'm more confused now than before
I began.  All of the examples seem to have everything on a single box,
and I have been able to set up a test repos on the test box, but I must
be in the svn bin directory as root to execute any command, unlike the
examples that have you executing commands from different directories.
All directories that I set up have group read write execute permissions.


 

Question 1, How should I have groups and users set up so that I can
execute from any directory?

 

I cant find any examples of accessing a repository that is on a
different system UNIX -> Win  or Win -> UNIX.   

 

Question 2, What would the syntax be for that?

 

Question 3, What is the default port for svn?

 

If someone could point me to specific examples or  give any advice it
would be greatly appreciated.

 

Thanks

 

 

John Birdsell

 

IT Specialist 

US Dept of Labor

Office of Inspector General

200 Constitution Ave, NW

Room S5020

Washington, DC 20210

 

(202) 693-7055 

 

birdsell.j...@oig.dol.gov  

 

Re: startup questions

[vishwajeet singh]

On Thu, Jun 10, 2010 at 6:17 PM, Birdsell, John - OIG <
birdsell.j...@oig.dol.gov> wrote:

>  Hello,
>
>
>
> I am new to svn, and have inherited the project of installing and
> implementing version control.  Currently we are not using any form of
> version control
>
>
>
> A little background; our current environment set up is, develop on local
> machines (win) ftp to test (Unix) on approval, ftp from local to production
> (Unix) and we developing in ColdFusion.   The versioning project was started
> about 6 months ago and the two people on the project, a dba and a developer
> both left a month into it and of course left no documentation as to their
> progress.
>
>
>
> I currently have svn v.1.6.6 installed on our test box.
>
> I have read:  svnbook.red-bean.com for 1.6 and “Pragmatic Version Control
> using Subversion 2nd ed.” And I’m more confused now than before I began.
> All of the examples seem to have everything on a single box, and I have been
> able to set up a test repos on the test box, but I must be in the svn bin
> directory as root to execute any command, unlike the examples that have you
> executing commands from different directories. All directories that I set up
> have group read write execute permissions.
>
>
>
> Question 1, How should I have groups and users set up so that I can execute
> from any directory?
>
you need to setup a server and create authorization file to give access to
users, your system users and group are not necessarily the same as
Subversion authorization file

> I cant find any examples of accessing a repository that is on a different
> system UNIX -> Win  or Win -> UNIX.
>
Once you setup server it does not matter whether client is on windows or
linux.

>
>
> Question 2, What would the syntax be for that?
>
Each repository created has format for authorization file inside it so you
can see that for reference

>
>
> Question 3, What is the default port for svn?
>
it's 3980 but I am not sure

>
>
> If someone could point me to specific examples or  give any advice it would
> be greatly appreciated.
>
>
>
> Thanks
>
>
>
>
>
> *John Birdsell*
>
>
>
> *IT Specialist*
>
> US Dept of Labor
>
> Office of Inspector General
>
> 200 Constitution Ave, NW
>
> Room S5020
>
> Washington, DC 20210
>
>
>
> (202) 693-7055
>
>
>
> birdsell.j...@oig.dol.gov
>
>
>



-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

Re: Functionality change request for revision compare

[Stefan Sperling]

On Thu, Jun 10, 2010 at 05:16:40AM -0700, K F wrote:
> I was comparing two tags and if I select the older revision first 
> it correctly shows a folder and the files under it as added. If I
>  select the newer one first it shows the same directory as 
> deleted but does not show the files under it as deleted. Is 
> there a reason why it could not show the files under it as 
> deleted? By not
>  showing the files there is no reference to them as being a 
> difference between the tags. It does the same thing if you just 
> check between revisions.

This is a known problem. It's unlikely to be fixed in the 1.6.x line.
Maybe in 1.7. Maybe later.

See http://subversion.tigris.org/issues/show_bug.cgi?id=2333
for details.

Stefan

Re: startup questions

[Ryan Schmidt]

On Jun 10, 2010, at 07:47, Birdsell, John - OIG wrote:

> I have read:  svnbook.red-bean.com for 1.6 and “Pragmatic Version Control 
> using Subversion 2nd ed.” And I’m more confused now than before I began.

Sorry to hear that! I found the Red Bean book quite clear and helpful, starting 
with no version control background.


> All of the examples seem to have everything on a single box,

I haven't read Pragmatic Version Control but in the Red Bean book that's 
certainly not the case. See for example:

http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.advanced.reposurls


> and I have been able to set up a test repos on the test box, but I must be in 
> the svn bin directory as root to execute any command, unlike the examples 
> that have you executing commands from different directories.

That should not be. What happens otherwise? What are the permissions of the svn 
command?


> All directories that I set up have group read write execute permissions.
>  
> Question 1, How should I have groups and users set up so that I can execute 
> from any directory?
>  
> I cant find any examples of accessing a repository that is on a different 
> system UNIX -> Win  or Win -> UNIX.  
>  
> Question 2, What would the syntax be for that?

Set up a server:

http://svnbook.red-bean.com/en/1.5/svn.serverconfig.html

Then just access the repository's URL. Depending on what server you choose, 
your URL might begin with http, https, svn or svn+ssh.


> Question 3, What is the default port for svn?

It depends on the protocol you use:

http: 80
https: 443
svn: 3690
svn+ssh: 22

For any of these you can change the port to something nonstandard if desired.

File externals included in svn status --quite

[Kevinm]

When running svn status in an unmodified working copy, file externals are
included in the output regardless of whether the --quiet flag is supplied.
This seems wrong as my assumption is that running status with the --quiet
flag on a unmodified wc should return no output.

This breaks the current version of svnmerge.py as it assumes that a wc has
local modifications if running 'svn status --quiet --ignore-externals'
produces any output.

Running status with --ignore-externals also has no effect on file externals
but this seems correct as a file external is treated as a normal file when
committing (just with a different repository parent).

Are my assumptions correct? If so, I'll post to the developers list.

Thanks.

replacing all code with latest SVN regardless of conflicts or uncommitted changes or whatever

[Thomas Anderson]

Say I've added a bunch of debug code to files in a particular
directory and that I want to now remove all the debug code.  I could
search through the file and manually remove it all or I could just re
checkout the directory from SVN and replace the debug directory with
the latest SVN code.  Problem is, typing in "svn checkout" requires
you know the URL of the repository / directory you're checking out.

If you could do something like "svn refresh" and have it just look at
the .svn/entries file to get the URL that'd be a lot easier.  I mean,
ease of use is why "svn update" exists.  You could just recheck out a
repository every time you wanted to update your code to the latest
version and manually do diffs comparing the newly checked out against
your own and merging where conflicts exist as appropriate but "svn
update" makes it a lot easier.  Similarly, although technically maybe
unnecessary, I think an "svn refresh" command would be nice.

Re: replacing all code with latest SVN regardless of conflicts or uncommitted changes or whatever

[Tyler Roscoe]

On Thu, Jun 10, 2010 at 10:46:26AM -0500, Thomas Anderson wrote:
> Say I've added a bunch of debug code to files in a particular
> directory and that I want to now remove all the debug code.  I could
> search through the file and manually remove it all or I could just re
> checkout the directory from SVN and replace the debug directory with
> the latest SVN code.  Problem is, typing in "svn checkout" requires
> you know the URL of the repository / directory you're checking out.

rm -rf bad_directory
svn update bad_directory

should do the trick.

tyler

Re: replacing all code with latest SVN regardless of conflicts or uncommitted changes or whatever

[Les Mikesell]

Thomas Anderson wrote:

Say I've added a bunch of debug code to files in a particular
directory and that I want to now remove all the debug code.  I could
search through the file and manually remove it all or I could just re
checkout the directory from SVN and replace the debug directory with
the latest SVN code.  Problem is, typing in "svn checkout" requires
you know the URL of the repository / directory you're checking out.

If you could do something like "svn refresh" and have it just look at
the .svn/entries file to get the URL that'd be a lot easier.  I mean,
ease of use is why "svn update" exists.  You could just recheck out a
repository every time you wanted to update your code to the latest
version and manually do diffs comparing the newly checked out against
your own and merging where conflicts exist as appropriate but "svn
update" makes it a lot easier.  Similarly, although technically maybe
unnecessary, I think an "svn refresh" command would be nice.


How about 'revert' followed by an 'update'?

--
  Les Mikesell
   lesmikes...@gmail.com

Re: Two svn/apache servers accessing one database

[Les Mikesell]

Stephen Connolly wrote:
On 10 June 2010 06:34, Richard England > wrote:


On 06/08/2010 01:48 AM, Ulrich Eckhardt wrote:

On Saturday 05 June 2010, Richard England wrote:
  

Are there any possible repercussions of having two server both running
Apache/SVN (same version)  accessing the same database files?  This is
using FSFS.

Is this likely to cause data corruption or anything nasty?

You can easily have multiple concurrent accesses even without running two 
Apaches, e.g. concurrent file accesses by different users on the same 
machine, different svn+ssh sessions, multiple svnserve instances spawned by 
[x]inetd etc.


In other words, it works.

Uli

  


Andy, the rationale is to allow a team to migrate from one server to
another over time rather than forcing them to move their working
copies before it makes sense in their development process.  They are
aware they can use "svn switch --relocate" to update the working
copes but this would make it a little more palatable for them.

Than you Andy, and Uli.

-- 


/~~R/



Why not just have the old server issue a 301/302 to the new server 
location (I can never remember which is moved permanently)?


I haven't tried it, but you should also be able to use apache's ProxyPass or a 
RewriteRule that triggers a proxy to the new server to make it completely 
transparent.


--
  Les Mikesell
   lesmikes...@gmail.com

svn move directory will create a new revision for every file inside this directory?

[Leonardo Azize Martins]

Hi,

The command below will create a new revision for directory SRC_REP_DIR?
And for files inside this directory? Had a new revision too?

"svn move SRC_REP_DIR DST_REP_DIR"

Command above use repository not WC.


Regards,
Leo

RE: svn move directory will create a new revision for every file inside this directory?

[Bob Archer]

> The command below will create a new revision for directory SRC_REP_DIR?
> And for files inside this directory? Had a new revision too?
> 
> "svn move SRC_REP_DIR DST_REP_DIR"
> 
> Command above use repository not WC.

That command is going to basically going to be the same as:

svn copy SRC_REP_DIR DST_REP_DIR
svn delete SRC_REP_DIR

Yes... a new revision will be created. The new path will be in HEAD and the old 
path will not be.

BOb

Re: can I use svn:externals instead of svn copy to create a tag?

[Daniel Becroft]

On Fri, Jun 11, 2010 at 6:42 AM, Gary Hallmark  wrote:
> All examples I have seen for tagging use svn copy (or svncopy -tag) to
> create a tag. If I want to make sure nobody can change the tag, I guess I
> could write a commit hook. But couldn't I use a versioned external
> definition to create the tag instead of svn copy? Seems this would better
> enforce that nobody can change the tag, since it isn't a copy at all. One
> downside would be that if the tag contains unversioned externals, I would
> not be able to pin them down, but I don't plan to have unversioned
> externals. Are there any other downsides?
>
> Example:
> trunk/
> tags/
>   X -r123 ^trunk version_1.0

You would still need to enforce (via a commit hook) that no-one can
modify the version_1.0 external definition to point to -r456 instead.
Not sure how much simpler (or more difficult) this would be over
having standard folders.

BTW, I think the definition you might want to use is ^tr...@123,
rather than -r123 ^trunk, but I could be wrong.

Cheers,
Daniel B.

Re: can I use svn:externals instead of svn copy to create a tag?

[Rob van Oostrum]

On Thu, Jun 10, 2010 at 4:42 PM, Gary Hallmark wrote:

> All examples I have seen for tagging use svn copy (or svncopy -tag) to
> create a tag. If I want to make sure nobody can change the tag, I guess I
> could write a commit hook. But couldn't I use a versioned external
> definition to create the tag instead of svn copy? Seems this would better
> enforce that nobody can change the tag, since it isn't a copy at all. One
> downside would be that if the tag contains unversioned externals, I would
> not be able to pin them down, but I don't plan to have unversioned
> externals. Are there any other downsides?
>
> Example:
> trunk/
> tags/
>   X -r123 ^trunk version_1.0
>
> Cheers,
>  Gary
>

The primary downside to this that I see, is that you won't be able to
address a tag via URL (e.g. for the purpose of creating a branch), because
the tags' paths will only exist in a working copy, and you probably don't
want to checkout all of /tags.

RE: svn move directory will create a new revision for every file inside this directory?

[Bob Archer]

> Thanks for you replay.
> 
> I heve the structure below:
> 
> DIR_A - Rev 1
> > File_A - Rev 2
> DIR_B - Rev 3
> 
> If I move DIR_A to inside DIR_B the structure will be as:
> 
> DIR_B - Rev 3
> >DIR_A - Rev 4
> >> File_A - Rev 2
> 
> So, the directory has a new revision (Rev 4), but files inside this
> directory does not ( Rev 2).
> 
> If i try to get this file from:
>  - REV: 2
>  - PEGREV: 2
>  - Path: DIR_B/DIR_A/FILE_A
> svn show error, because this path is not valid in PEGREV 2.
> 
> Regards,
> Leo

Yes... you are 100% correct. What is your question? 

I think you may be making the mistake of expecting the each file is revisioned 
separately. That is not the case. In rev2-4 your File_A is the same. however, 
in rev4 its path in the repo is different than in rev2. But, I'm babbling 
without really knowing what your question is. Have you read the first chapter 
of the doc redbook? http://svnbook.red-bean.com/nightly/en/svn-book.html

BOb


> 
> 
> 
> 2010/6/10 Bob Archer :
> >> The command below will create a new revision for directory SRC_REP_DIR?
> >> And for files inside this directory? Had a new revision too?
> >>
> >> "svn move SRC_REP_DIR DST_REP_DIR"
> >>
> >> Command above use repository not WC.
> >
> > That command is going to basically going to be the same as:
> >
> > svn copy SRC_REP_DIR DST_REP_DIR
> > svn delete SRC_REP_DIR
> >
> > Yes... a new revision will be created. The new path will be in HEAD and
> the old path will not be.
> >
> > BOb
> >
> >

Re: svn move directory will create a new revision for every file inside this directory?

[Leonardo Azize Martins]

Hi Bob,

Thanks for you replay.

I heve the structure below:

DIR_A - Rev 1
> File_A - Rev 2
DIR_B - Rev 3

If I move DIR_A to inside DIR_B the structure will be as:

DIR_B - Rev 3
>DIR_A - Rev 4
>> File_A - Rev 2

So, the directory has a new revision (Rev 4), but files inside this
directory does not ( Rev 2).

If i try to get this file from:
 - REV: 2
 - PEGREV: 2
 - Path: DIR_B/DIR_A/FILE_A
svn show error, because this path is not valid in PEGREV 2.

Regards,
Leo



2010/6/10 Bob Archer :
>> The command below will create a new revision for directory SRC_REP_DIR?
>> And for files inside this directory? Had a new revision too?
>>
>> "svn move SRC_REP_DIR DST_REP_DIR"
>>
>> Command above use repository not WC.
>
> That command is going to basically going to be the same as:
>
> svn copy SRC_REP_DIR DST_REP_DIR
> svn delete SRC_REP_DIR
>
> Yes... a new revision will be created. The new path will be in HEAD and the 
> old path will not be.
>
> BOb
>
>

RE: Migrating to SVN from zipfile-based archival. Advice?

[Erik Hemdal]

> -Original Message-
> From: Barry Callahan [mailto:bar...@rjlsystems.com]
> Sent: Thursday, June 10, 2010 5:26 PM
> To: users@subversion.apache.org
> Subject: Migrating to SVN from zipfile-based archival. Advice?
. . . .
>
> Using the standard layout, I figured the current source would get
> imported under trunk/ and each snapshot  should be unzipped and
> imported
> as a tag (eg: tags/release_x).

Hi Barry,

I had to do something similar when we first began using SVN.  I had available 
copies of older revisions of projects, and I used them to modify a working 
copy, and committed each revision onto trunk, in "date order".  I finished up 
with the "current source" which got committed last.

With appropriate comments, this was an attempt to capture what I had of the 
revision history.  Then I created tags from the various trunk revisions as I 
went along.  It took a bit of work, but preserved what history I could.

If you do this, you need to be watchful when new files are added to or dropped 
from the project, because you need to "svn add" or "svn delete" them as you go.

>
> If I understood correctly, unlike, say, RCS, since SVN doesn't version
> individual files, I guess it doesn't matter so much what order things
> get imported in. Right?

If you simply import sets of files straight to a tag, I agree with you.  But it 
would matter if you were trying to capture (or shall I say, recreate) history.

>
> If I follow this course of action, would I end up being penalized in
> terms of disk usage or performance over some other, preferred method?

Well, you'll need more disk space anytime you can't avoid a cheap copy, such as 
upon an "svn import".  But I'd lean toward getting the files into the 
repository in a way that makes sense to you, and let disk usage go where it may.

I won't say this is a preferred method, but it worked for me.  I had all my 
files in the repository and I understood what I had done.

>
> Is the SVN server smart enough to realize that, even if I follow this
> course of action, that
>
> /trunk/foo/bar.c
> /tags/release1/foo/bar.c
> /tags/release2/foo/bar.c
>
> are all the same file with minor (if any) differences?

No.  If you import files as you described, SVN has no way to capture that two 
files in different locations with the same name are related.  If you first 
commit to trunk and then make tags, you can set up those relationships. The 
tags, which are copied from trunk, are "cheap copies" as I recall.

Erik

can I use svn:externals instead of svn copy to create a tag?

[Gary Hallmark]

All examples I have seen for tagging use svn copy (or svncopy -tag) to 
create a tag. If I want to make sure nobody can change the tag, I guess 
I could write a commit hook. But couldn't I use a versioned external 
definition to create the tag instead of svn copy? Seems this would 
better enforce that nobody can change the tag, since it isn't a copy at 
all. One downside would be that if the tag contains unversioned 
externals, I would not be able to pin them down, but I don't plan to 
have unversioned externals. Are there any other downsides?


Example:
trunk/
tags/
   X -r123 ^trunk version_1.0

Cheers,
 Gary

Re: Migrating to SVN from zipfile-based archival. Advice?

[Les Mikesell]

Barry Callahan wrote:
I've been using zipfiles to make snapshots of my development 
directories. Recently, I've decided maybe a solution that's a little 
more robust might be in order, so I'm looking to migrate to SVN.


I'd like a bit of advice on how to go about doing that. Perhaps even 
just a sanity check.


Using the standard layout, I figured the current source would get 
imported under trunk/ and each snapshot  should be unzipped and imported 
as a tag (eg: tags/release_x).


If I understood correctly, unlike, say, RCS, since SVN doesn't version 
individual files, I guess it doesn't matter so much what order things 
get imported in. Right?


If I follow this course of action, would I end up being penalized in 
terms of disk usage or performance over some other, preferred method?


Is the SVN server smart enough to realize that, even if I follow this 
course of action, that


/trunk/foo/bar.c
/tags/release1/foo/bar.c
/tags/release2/foo/bar.c

are all the same file with minor (if any) differences?


No, importing separately will preserve your snapshots but svn won't have any 
concept of the history of any copy.  You should probably look at the 
documentation related to 'vendor drops' to see the procedure and tools for 
handling snapshots that were made outside of version control so svn understands 
their relationships.


--
  Les Mikesell
   lesmikes...@gmail.com

RE: Migrating to SVN from zipfile-based archival. Advice?

[Bob Archer]

> I've been using zipfiles to make snapshots of my development
> directories. Recently, I've decided maybe a solution that's a little
> more robust might be in order, so I'm looking to migrate to SVN.
> 
> I'd like a bit of advice on how to go about doing that. Perhaps even
> just a sanity check.
> 
> Using the standard layout, I figured the current source would get
> imported under trunk/ and each snapshot  should be unzipped and imported
> as a tag (eg: tags/release_x).
> 
> If I understood correctly, unlike, say, RCS, since SVN doesn't version
> individual files, I guess it doesn't matter so much what order things
> get imported in. Right?
> 
> If I follow this course of action, would I end up being penalized in
> terms of disk usage or performance over some other, preferred method?
> 
> Is the SVN server smart enough to realize that, even if I follow this
> course of action, that
> 
> /trunk/foo/bar.c
> /tags/release1/foo/bar.c
> /tags/release2/foo/bar.c
> 
> are all the same file with minor (if any) differences?

If you do this you are going to get several copies. 

What I would do is create a trunk and import the oldest ZIP that you have. Then 
get a check out of trunk and copy your next version over it. Do and "add" and 
"commit" then tag it. Continue.

Actually, there is a utility that is designed to import ZIPs that are different 
versions. Although now that everything is at apache.org I don't know where to 
find all the little utilties that used to be on tigris.org... and they don't 
seem to be at tigris.org either.

BOb

Migrating to SVN from zipfile-based archival. Advice?

[Barry Callahan]

I've been using zipfiles to make snapshots of my development 
directories. Recently, I've decided maybe a solution that's a little 
more robust might be in order, so I'm looking to migrate to SVN.


I'd like a bit of advice on how to go about doing that. Perhaps even 
just a sanity check.


Using the standard layout, I figured the current source would get 
imported under trunk/ and each snapshot  should be unzipped and imported 
as a tag (eg: tags/release_x).


If I understood correctly, unlike, say, RCS, since SVN doesn't version 
individual files, I guess it doesn't matter so much what order things 
get imported in. Right?


If I follow this course of action, would I end up being penalized in 
terms of disk usage or performance over some other, preferred method?


Is the SVN server smart enough to realize that, even if I follow this 
course of action, that


/trunk/foo/bar.c
/tags/release1/foo/bar.c
/tags/release2/foo/bar.c

are all the same file with minor (if any) differences?

Thanks.

Re: Migrating to SVN from zipfile-based archival. Advice?

[Lieven Govaerts]

[..]

>> Is the SVN server smart enough to realize that, even if I follow this
>> course of action, that
>>
>> /trunk/foo/bar.c
>> /tags/release1/foo/bar.c
>> /tags/release2/foo/bar.c
>>
>> are all the same file with minor (if any) differences?
>
> If you do this you are going to get several copies.
>
> What I would do is create a trunk and import the oldest ZIP that you have. 
> Then get a check out of trunk and copy your next version over it. Do and 
> "add" and "commit" then tag it. Continue.
>
> Actually, there is a utility that is designed to import ZIPs that are 
> different versions. Although now that everything is at apache.org I don't 
> know where to find all the little utilties that used to be on tigris.org... 
> and they don't seem to be at tigris.org either.
>

All files from svn.collab.net have been copied to svn.apache.org.
You're probably talking about svn_load_dirs.pl, which is the tool that
the documentation refers to in the 'vendor drop' chapter. You can find
it here:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/

hth,

Lieven

Re: can I use svn:externals instead of svn copy to create a tag?

[David Weintraub]

I already have a pre-commit hook that just does this. You can set an
"add-only" parameter which allows you to copy files into that
directory, but not modify files in that directory.

Take a look at it: http://dl.dropbox.com/u/433257/hooks.zip.

On Thu, Jun 10, 2010 at 4:42 PM, Gary Hallmark  wrote:
> All examples I have seen for tagging use svn copy (or svncopy -tag) to
> create a tag. If I want to make sure nobody can change the tag, I guess I
> could write a commit hook. But couldn't I use a versioned external
> definition to create the tag instead of svn copy? Seems this would better
> enforce that nobody can change the tag, since it isn't a copy at all. One
> downside would be that if the tag contains unversioned externals, I would
> not be able to pin them down, but I don't plan to have unversioned
> externals. Are there any other downsides?
>
> Example:
> trunk/
> tags/
>   X -r123 ^trunk version_1.0
>
> Cheers,
>  Gary
>



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

Re: Migrating to SVN from zipfile-based archival. Advice?

[Ryan Schmidt]

On Jun 10, 2010, at 17:24, Lieven Govaerts wrote:

>>> Is the SVN server smart enough to realize that, even if I follow this
>>> course of action, that
>>> 
>>> /trunk/foo/bar.c
>>> /tags/release1/foo/bar.c
>>> /tags/release2/foo/bar.c
>>> 
>>> are all the same file with minor (if any) differences?
>> 
>> If you do this you are going to get several copies.
>> 
>> What I would do is create a trunk and import the oldest ZIP that you have. 
>> Then get a check out of trunk and copy your next version over it. Do and 
>> "add" and "commit" then tag it. Continue.
>> 
>> Actually, there is a utility that is designed to import ZIPs that are 
>> different versions. Although now that everything is at apache.org I don't 
>> know where to find all the little utilties that used to be on tigris.org... 
>> and they don't seem to be at tigris.org either.
>> 
> 
> All files from svn.collab.net have been copied to svn.apache.org.
> You're probably talking about svn_load_dirs.pl, which is the tool that
> the documentation refers to in the 'vendor drop' chapter. You can find
> it here:
> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/

Yes, svn_load_dirs.pl is exactly the script you want for this scenario. It's 
how I initially imported my make-a-copy-every-so-often pseudo-version-control 
into Subversion years ago.