Regarding shallow checkouts

[An Me]

Hi All,

I am learning svn and am a new-bie.The following is my doubt.

What is the significance of shallow checkouts.?.
Why would somebody want to checkout a project partially.?
If possible please explain with a scenario/real life example.

Regards,
An

RE: Expected release date of RedBean for 1.6

[David Aldrich]

Hi Stefan

> I've added a new section to the book explaining how to keep
> a branch alive after reintegration.

Thanks very much for adding this new section. This method may well be useful to 
us. Currently, we are running svn client 1.6.9 against svn server 1.5.2.  Will 
this combination support the "svn merge --record-only" method that you 
described?

Best regards

David

Attachments

[Rob Hubbard]

Hello,

What are the options for posting questions with attachments to this
mailing please?

Specifically:
(1) are attachments possible?
(2) if so, what file types are permitted (especially zips, scripts,
images)?
(3) presumably, any attachments should be small, but is there a specific
size limit?
(4) is the presence of attachments dependent on the host (e.g.
http://mail-archives.apache.org/mod_mbox/subversion-users/ versus
http://svn.haxx.se/users/)?

This does not seem to be covered on the page
http://subversion.apache.org/docs/community-guide/mailing-lists.html

Thanks,
Rob.

PS. please CC me on replies.


This message has been independently scanned for the Softel Group and cleared of 
containing viruses and other malicious data.

Powering Television Beyond the Video (TM)

Passwords stored in gnome-keyring lack a description

[Matthijs Kooijman]

(Please CC me, I am not on the list)

Hi,

it seems any network passwords that are stored by subversion in the
gnome-keyring do not get any description. In my gnome-keyring-manager they
just show up as "network password", which is of course very uninformative.
Looking at the code, it seems gnome_keyring_set_network_password_sync, which
is used to set the password, does not allow setting the display name.

However, using gnome-keyring-manager I can change the description, so I think
that a separate display name is stored for each password. Perhaps using
gnome_keyring_item_info_set_display_name and gnome_keyring_item_set_info_sync
the display name could be set afterwards?

Gr.

Matthijs


signature.asc
Description: Digital signature

Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?

[Neels J Hofmeyr]

(This mail was posted to dev@ -- redirecting to users@)

Johan Corveleyn wrote:
> Hi devs,
> 
> A small question in anticipation of 1.7: will an (FSFS) repo benifit
> from a dump/reload when upgrading from 1.6 to 1.7? Or will a simple
> "upgrade" (followed maybe by a "pack" to pack the revprops) provide
> just the same?
> 
> Reason for asking: We're currently still running on 1.5, and planning
> to upgrade to 1.6 soon. Tests have shown us that doing a dump/reload
> during this upgrade will give some benefit (due to rep-sharing
> probably), but nothing huge. So I'm just wondering whether to do a
> dump/reload now (to be in the best possible shape for the future), or
> that I'll have to do another dump/reload when going to 1.7 in order to
> get maximum benifits. In the latter case, I will probably not do a
> dump/reload now (just upgrade to 1.6), and defer that until we upgrade
> to 1.7...
> 
> Kind regards,
> Johan

Just a side note, we are expecting most users to still be using 1.6 servers
with their 1.7 clients for a while. But 1.7 will probably move to SHA1
checksums instead of MD5, and there will be some duplicate checksum
calculation when pairing up a 1.7 client with older servers. ...but a)
duplicate checksums might also be necessary even with 1.7 client <-> 1.7
server, and b) we don't expect *that* to impact performance, really.

1.7 servers may also allow you to obliterate revisions, but we don't know
that yet.

Anyone else know of a particular server side improvement planned for 1.7?
(I'm rather ignorant, really)

~Neels



signature.asc
Description: OpenPGP digital signature

Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?

[Johan Corveleyn]

On Mon, Feb 22, 2010 at 1:35 PM, Neels J Hofmeyr  wrote:
> (This mail was posted to dev@ -- redirecting to users@)
>
> Johan Corveleyn wrote:
>> Hi devs,
>>
>> A small question in anticipation of 1.7: will an (FSFS) repo benifit
>> from a dump/reload when upgrading from 1.6 to 1.7? Or will a simple
>> "upgrade" (followed maybe by a "pack" to pack the revprops) provide
>> just the same?
>>
>> Reason for asking: We're currently still running on 1.5, and planning
>> to upgrade to 1.6 soon. Tests have shown us that doing a dump/reload
>> during this upgrade will give some benefit (due to rep-sharing
>> probably), but nothing huge. So I'm just wondering whether to do a
>> dump/reload now (to be in the best possible shape for the future), or
>> that I'll have to do another dump/reload when going to 1.7 in order to
>> get maximum benifits. In the latter case, I will probably not do a
>> dump/reload now (just upgrade to 1.6), and defer that until we upgrade
>> to 1.7...
>>
>> Kind regards,
>> Johan
>
> Just a side note, we are expecting most users to still be using 1.6 servers
> with their 1.7 clients for a while. But 1.7 will probably move to SHA1
> checksums instead of MD5, and there will be some duplicate checksum
> calculation when pairing up a 1.7 client with older servers. ...but a)
> duplicate checksums might also be necessary even with 1.7 client <-> 1.7
> server, and b) we don't expect *that* to impact performance, really.
>
> 1.7 servers may also allow you to obliterate revisions, but we don't know
> that yet.
>
> Anyone else know of a particular server side improvement planned for 1.7?
> (I'm rather ignorant, really)

Thanks for your answer, Neels. But it doesn't really answer my question :).

I was not asking whether upgrading the server to 1.7 would be
benificial, but whether *dump/reload* would provide any benifit over
just upgrading to 1.7. Of course this is really a hypothetical
question as 1.7 doesn't exist yet. But given what's currently on the
table for 1.7 (as far as it is already known). Does anyone know?

As for using the SHA1 checksum, I'm wondering if it would make any
difference whether or not you reload the repo: as of 1.6 the (FSFS)
repo already contains SHA1 hashes. If I understand the FSFS
"structure" document [1] correctly (section "Revision file format", in
the list "The following fields are defined"), as of format 4 (SVN 1.6)
it already contains SHA1 checksums for the representations. Of course,
I may be misunderstanding the doc, or misunderstanding what's going to
be needed for 1.7...

That same document currently does not describe any differences between
format 4 (SVN 1.6) and format 5 (SVN 1.7) in the section "Filesystem
formats". Which is kind of odd (why bump the filesystem format if
there are no differences)...

As for the redirection to users@: sorry if I initially picked the
wrong audience (I'm quite careful with that sort of thing, don't want
to generate noise). But in this case I just thought dev@ was the
correct forum. Although this is a "usage" question, it's about usage
of a version that nobody uses yet. I'm guessing that only the devs, if
anyone, currently have an idea what the answer will be to that
question :). Anyway, doesn't matter that much to me, but any insight
anyone can offer would still be very helpful ...

Johan

[1] 
http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure

log shows unintended object's history even with a peg

[Rob Hubbard]

Hello,

I have a project that happens to have two separate objects
with the same path.

SVN seems to make it difficult to view the history of objects
other than those present at the HEAD, unless you already know
certain key historical revision numbers.

[I have tried this with SVN 1.6.6 and SlikSVN 1.6.9]

As a simplified example, suppose the history is like this:

  trunk/ branch/
  r1
 --cp-->
 r2
  r3
 r4
  r5 (rm)
 r6
 <--mv--
  r7
  r8

The full history on the entire repository might look like this:

  > svn log -vr 1:HEAD "file://localhost/c:/Temp/spb_repo/"
  --
  r1 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 A /trunk
 A /trunk/file.txt
  initial version
  --
  r2 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 A /branch (from /trunk:1)
  create branch
  --
  r3 | robh | 2010-02-22 11:25:22 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 M /trunk/file.txt
  trunk edit
  --
  r4 | robh | 2010-02-22 11:25:22 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 M /branch/file.txt
  branch edit
  --
  r5 | robh | 2010-02-22 11:25:23 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 D /trunk
  trunk delete
  --
  r6 | robh | 2010-02-22 11:25:23 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 M /branch/file.txt
  further branch edit
  --
  r7 | robh | 2010-02-22 11:25:24 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 D /branch
 A /trunk (from /branch:6)
  move branch back to trunk
  --
  r8 | robh | 2010-02-22 11:25:24 + (Mon, 22 Feb 2010) | 1 line
  Changed paths:
 M /trunk/file.txt
  new-trunk edit
  --

By trying to use peg and operative revisions,
I get the following responses

  > REM *** (1) log trunk ***
  > svn log -qr 1:HEAD "file://localhost/c:/Temp/spb_repo/"trunk
  --
  r1 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r2 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r4 | robh | 2010-02-22 11:25:22 + (Mon, 22 Feb 2010)
  --
  r6 | robh | 2010-02-22 11:25:23 + (Mon, 22 Feb 2010)
  --
  r7 | robh | 2010-02-22 11:25:24 + (Mon, 22 Feb 2010)
  --
  r8 | robh | 2010-02-22 11:25:24 + (Mon, 22 Feb 2010)
  --

  > REM *** (2) log branch ***
  > svn log -qr 1:6 "file://localhost/c:/Temp/spb_repo/"bra...@2
  --
  r1 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r2 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r4 | robh | 2010-02-22 11:25:22 + (Mon, 22 Feb 2010)
  --
  r6 | robh | 2010-02-22 11:25:23 + (Mon, 22 Feb 2010)
  --

  > REM *** (3) log branch ? ***
  > svn log -qr 1:HEAD "file://localhost/c:/Temp/spb_repo/"bra...@2
  svn: File not found: revision 8, path '/branch'

  > REM *** (4) log old trunk ***
  > svn log -qr 1:4 "file://localhost/c:/Temp/spb_repo/"tr...@1
  --
  r1 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r3 | robh | 2010-02-22 11:25:22 + (Mon, 22 Feb 2010)
  --

  > REM *** (5) log old trunk ? ***
  > svn log -qr 1:HEAD "file://localhost/c:/Temp/spb_repo/"tr...@1
  --
  r1 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r2 | robh | 2010-02-22 11:25:21 + (Mon, 22 Feb 2010)
  --
  r4 | robh | 2010-02

Re: Regarding shallow checkouts

[Felix Gilcher]

Well, my scenario is simple: I have a repository that contains a folder 
branches and in that folder is a branch for every version that is deployed. 
Deployment is done every second week, since 2007. So that's a lot of branches. 
I use shallow checkout to check out the branches folder and all of its 
immediate children which gives me a list of existing branches. If I need to 
work on one of those, I can pull it easily with svn up --set-depth=infinity. 

That's about all.

felix

On Feb 22, 2010, at 11:28 AM, An Me wrote:

> Hi All,
> 
> I am learning svn and am a new-bie.The following is my doubt.
> 
> What is the significance of shallow checkouts.?.
> Why would somebody want to checkout a project partially.?
> If possible please explain with a scenario/real life example.
> 
> Regards,
> An

--
Felix Gilcher

Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München

Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever

svn switch does not update relative externals

[Olivier Sannier]

Hello all,

Let's say we have the following repository:

/trunk
/trunk/bin
/trunk/sources/report_engine/models

and an external on bin defined as the following:

../sources/report_engine/models models

so when I checkout trunk, I get a copy of 
/trunk/sources/report_engine/models inside the bin/models folder.

This is very convenient to have "symbolic links" inside a repository.

Now I do this:
svn cp /trunk /branches/test

then I modify a file inside /trunk/sources/report_engine/models and 
commit it.

Finally, I want to work on the branch and switch my working copy to it:

svn switch /branches/test .

While it updates my working copy to match all the changes made into the 
branch, it never updates bin/models to represent the content of 
/branches/test/sources/report_engine/models


I reread the svn book and it is not clear to me whether or not svn 
switch is supposed to update a relative external.
To me it would be quite logical that it would, hence my surprise when I 
saw the above behavior. Could it be that I missed something obvious?


Regards
Olivier

Re: svn switch does not update relative externals

[Johan Corveleyn]

On Mon, Feb 22, 2010 at 3:31 PM, Olivier Sannier  wrote:
> Hello all,
>
> Let's say we have the following repository:
>
> /trunk
> /trunk/bin
> /trunk/sources/report_engine/models
>
> and an external on bin defined as the following:
>
> ../sources/report_engine/models models
>
> so when I checkout trunk, I get a copy of
> /trunk/sources/report_engine/models inside the bin/models folder.
> This is very convenient to have "symbolic links" inside a repository.
>
> Now I do this:
> svn cp /trunk /branches/test
>
> then I modify a file inside /trunk/sources/report_engine/models and commit
> it.
> Finally, I want to work on the branch and switch my working copy to it:
>
> svn switch /branches/test .
>
> While it updates my working copy to match all the changes made into the
> branch, it never updates bin/models to represent the content of
> /branches/test/sources/report_engine/models
>
> I reread the svn book and it is not clear to me whether or not svn switch is
> supposed to update a relative external.
> To me it would be quite logical that it would, hence my surprise when I saw
> the above behavior. Could it be that I missed something obvious?

I think this is a known bug. See
http://subversion.tigris.org/issues/show_bug.cgi?id=3390

It was recently fixed and proposed for backport to 1.6.x. It will
probably, hopefully, most likely, ... be included in 1.6.10.

Johan

Re: svn switch does not update relative externals

[Olivier Sannier]

Johan Corveleyn wrote:

On Mon, Feb 22, 2010 at 3:31 PM, Olivier Sannier  wrote:
   

I reread the svn book and it is not clear to me whether or not svn switch is
supposed to update a relative external.
To me it would be quite logical that it would, hence my surprise when I saw
the above behavior. Could it be that I missed something obvious?
 

I think this is a known bug. See
http://subversion.tigris.org/issues/show_bug.cgi?id=3390

It was recently fixed and proposed for backport to 1.6.x. It will
probably, hopefully, most likely, ... be included in 1.6.10.
   


Ah yes, you are right, this is exactly the same bug, don't know why I 
could not find it.

Well, let's hope it comes down in the next update to the 1.6 versions.

Regards
Olivier

regression: commiting a property change fails on windows, when working copy is on a samba share

[Attila Kinali]

Hi,

System:
Windows XP
svn 1.6.9 (collab)
tortoise 1.6.7, build 18415

We upgraded two weeks ago from svn 1.5.9 to 1.6.9.
Everything done here worked fine with 1.5.9.

When the working copy is on a samba(3.2.5 debian/stable) share,
editing and commiting a property fails with this error message:

---
Commit
Y:\work\scilab
Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
In directory 'Y:\work\scilab'
Error processing command 'committed' in 'Y:\work\scilab'
Can't move 'Y:\work\scilab\.svn\dir-props' to
'Y:\work\scilab\.svn\dir-prop-base': Access is denied.
---

Note: this is not a "normal" permission issue as all files have
the right permissions (created by the user himself). Logging in
on the samba server and commiting using the linux CLI client works.

This also works using the svn 1.5.9 on windows.

Only changes to properties fail, any other change works fine.

Any later svn command fails due to a remaining lock in the working copy.
svn cleanup fails with above error message if run on windows. (as said
above, it works fine running it on linux in the same directory).

My guess is, that svn has a file handle on dir-props open, while it
tries to move it. Which windows will refuse because the file is on
a remote file server.

Can anyone confirm this bug?

Thanks in advance

Attila Kinali
-- 
If you want to walk fast, walk alone.
If you want to walk far, walk together.
-- African proverb

Collect only the files changed

[Manickavel, Senthil]

Hi,
Is there a way to collect only the files changed between 2 revisions? 
(without the directories)

svn diff --summarize -r$FROM_REV:$TO_REV $URL_BASE

With Regards,
Senthil

The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.

Re: Collect only the files changed

[Ryan Schmidt]

On Feb 22, 2010, at 08:58, Manickavel, Senthil wrote:

> Is there a way to collect only the files changed between 2 revisions? 
> (without the directories)
> 
> svn diff --summarize -r$FROM_REV:$TO_REV $URL_BASE

"svn diff --summarize" shows you the names of the files that changed. You'll 
then have to write a script to collect those files.

Re: Regarding shallow checkouts

[Andrey Repin]

Greetings, An Me!

> I am learning svn and am a new-bie.The following is my doubt.

> What is the significance of shallow checkouts.?.
> Why would somebody want to checkout a project partially.?
> If possible please explain with a scenario/real life example.

If by shallow checkout you mean fetching of only certain depth of subdirs,
then "real-world" example is quite simple.
You need to change only one file. You co empty top-level directory, then
update only that file. And edit and commit it.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 22.02.2010, <19:22>

Sorry for my terrible english...

Re: merge doesn't merge changes - bug, but in which version?

[Chris Withers]

Chris Withers wrote:

Chris Withers wrote:
- svn co 
https://secure.simplistix.co.uk/svn/Simplistix/testfixtures/branches/1.8


- svn merge -r 4195:HEAD 
https://secure.simplistix.co.uk/svn/Simplistix/testfixtures/trunk .


Except this merges no changes :-(


Okay, so the server runs svn as supplied in debian stable, which is 1.5.1.

I tried taking a dump of the repository and creating a copy locally from 
the dump with the local svn version on my laptop, which is 1.6.0.


In this local copy, the merge works as expected.

*sigh*

So, what version of svn was this bug fixed in and where can I find out 
more about it?


Also, what's the recommended way for me to get a newer version (where 
this bug is fixed) on my debian server?


Just to close this out, I ended up moving the server to 1.6 via debian's 
backports and it solved the problem...


My love of svn continues to die :-(

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk

Re: Expected release date of RedBean for 1.6

[Tyler Roscoe]

On Mon, Feb 22, 2010 at 10:49:15AM +, David Aldrich wrote:
> Currently, we are running svn client 1.6.9 against svn server 1.5.2.
> Will this combination support the "svn merge --record-only" method
> that you described?

Yes.

tyler

Re: Expected release date of RedBean for 1.6

[Stefan Sperling]

On Mon, Feb 22, 2010 at 10:49:15AM +, David Aldrich wrote:
> Hi Stefan
> 
> > I've added a new section to the book explaining how to keep
> > a branch alive after reintegration.
> 
> Thanks very much for adding this new section. This method may well be
> useful to us. Currently, we are running svn client 1.6.9 against svn
> server 1.5.2.  Will this combination support the "svn merge
> --record-only" method that you described?

Sure, I don't see why not. Note however that merge-tracking related
fixes have been made during virtually every release in both the 1.5.x
and 1.6.x lines, so you may want to upgrade anyway.

Also, 1.5.2 has a known security issue which was fixed in 1.5.7.

Stefan

Re: regression: commiting a property change fails on windows, when working copy is on a samba share

[Stefan Sperling]

On Mon, Feb 22, 2010 at 03:50:21PM +0100, Attila Kinali wrote:
> ---
> Commit
> Y:\work\scilab
> Commit succeeded, but other errors follow:
> Error bumping revisions post-commit (details follow):
> In directory 'Y:\work\scilab'
> Error processing command 'committed' in 'Y:\work\scilab'
> Can't move 'Y:\work\scilab\.svn\dir-props' to
> 'Y:\work\scilab\.svn\dir-prop-base': Access is denied.
> ---
 
> Can anyone confirm this bug?

This looks like http://subversion.tigris.org/issues/show_bug.cgi?id=3053

Stefan

Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?

[Neels J Hofmeyr]

Sorry if I picked the wrong list there confusing Johan, but IMHO it *is* a
users@ question. It is not about *writing* the API or code, it is about
*using* the API/binaries, be it a future API or not.

I agree that it's sort of in-between. What drove me to redirect to users@ is
that others that read users@ might be asking themselves the same question.
We posted both now anyways, probably for the best ;)

About SHA1 on the 1.6 server: the point really is that we need to
communicate those SHA1 checksums to the client and back. Those API
mechanisms will be updated by 1.7 (or will they?). (I'm not 100% certain but
that's how I understood the conversations so far. Please correct me if I'm
wrong.)

~Neels

Daniel Shahaf wrote:
> Neels J Hofmeyr wrote on Mon, 22 Feb 2010 at 13:34 +0100:
>> Johan, I think this mail should have been sent to users@ instead. I am
>> replying there instead.
> 
> It don't find it off-topic on dev@, though, given that it asks about 
> unreleased features.  Not all devs read us...@.



signature.asc
Description: OpenPGP digital signature

Re: Strange output from reintegrate merge using JavaHL

[Mark Phippard]

JavaHL itself does not output anything.  It just sends notifications
and the code using JavaHL (svnClientAdapter in this case) turns it
into something.  Your output means that a notification came out of SVN
that the svnClientAdapter code did not have code to handle.  The best
thing would be to put the JhlNotificationHandler class in debug and
run the same merge and let us know what the unexpected values are so
that we can handle it.



On Sun, Feb 21, 2010 at 12:54 PM, Jacob Weber  wrote:
> Sometimes when I do a --reintegrate merge, I get some unexpected output, 
> along with the normal updates:
>
>    --- Merging differences between repository URLs into trunk-path
>    U   /trunk-path/file1
>    U   trunk-path/file2
>        trunk-path/file3
>        trunk-path/fil4
> ...
>
> That is, I see a bunch of filenames that have no status indicator. There were 
> hundreds of them in my latest merge.
>
> I'm using a Subversion 1.6.5 client, through Subclipse, using the JavaHL 
> interface, connecting to a 1.6.5 server.
>
> This output seems to be the result of a call to:
> org.tigris.subversion.javahl.mergeReintegrate(branch-url, HEAD, trunk-path, 
> false).
>
> Does anyone know why this might happen? Thanks,
> Jacob



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Automated Merging

[kd1]

Hi All,

 

For the last several months I've been working on a new project ... an
automated merging and branch management solutions designed for teams
that utilizing branches in their Subversion repositories.  MergeMagician
makes it much easier to manage multiple branches and keep them in sync
by automating the merge process between branches.

 

I'm at the point in the project where I'd like to get some people to try
it out.  If there's anyone that would be interested in taking a closer
look at it, please check out the web site http://www.mergemagician.com.
If you'd like to download it, shoot me an e-mail and I'll send you the
download link.

 

Thanks Everyone.

 

- Kevin Dietz

Timpani Software, Inc.

 

Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?

[Daniel Shahaf]

Neels J Hofmeyr wrote on Mon, 22 Feb 2010 at 18:37 +0100:
> About SHA1 on the 1.6 server: the point really is that we need to
> communicate those SHA1 checksums to the client and back. Those API

Communicate to the client?  Eh?  If those are the same checksums that go
into the rev file, I'd hope the server calculates them by itself and
doesn't rely on the client reporting them. (otherwise it would allow
malicious clients to corrupt the repository)

> mechanisms will be updated by 1.7 (or will they?). (I'm not 100% certain but
> that's how I understood the conversations so far. Please correct me if I'm
> wrong.)

Beginner admin question: organizing repository for student projects

[Stephen Bloch]

I want to get my undergraduate students in the habit of using svn,  
both for individual projects and for group projects.  I'd like to be  
able to create projects that belong to a whole class, and to an  
arbitrary subset of students, and to an individual student. And I'd  
like to be able to set up the repository once and for all so that I  
don't have to reorganize it every semester.  The usual "trunk/ 
branches/tags" organization didn't seem appropriate, at least at the  
top level.  Any advice from people who have set up a system like this?


I was thinking of something like this
users
joe
bob
mary
etc.
classes
cs160
cs171
thisproject
thatproject
cs172
theotherproject
thefourthproject
etc.

Each student would have a directory within users, with full access to  
that directory.
Each student would also have read access to the directory for each  
class the student was in, and write access to the directories for  
projects that the student is involved in.  The instructor of each  
class would have write access to the directory for that class.


Is this really stupid?  Am I "not getting" SVN?


Stephen Bloch
sbl...@adelphi.edu

Re: Will upgrade from 1.6 to 1.7 benifit from dump/reload?

[Daniel Shahaf]

Johan Corveleyn wrote on Mon, 22 Feb 2010 at 14:28 +0100:
> That same document currently does not describe any differences between
> format 4 (SVN 1.6) and format 5 (SVN 1.7) in the section "Filesystem
> formats".

That's a bug.

> Which is kind of odd (why bump the filesystem format if
> there are no differences)...

[ in ^/trunk/subversion/libsvn_fs_fs ]
% grep 5 *.h | grep FORMAT
fs.h:#define SVN_FS_FS__FORMAT_NUMBER   5
fs.h:#define SVN_FS_FS__MIN_PACKED_REVPROP_FORMAT 5

Not sure if there are other differences (i.e., grep might miss some).

Daniel

Re: Beginner admin question: organizing repository for student projects

[David Weintraub]

First of all, I'd like to congratulate you about getting your students
use to version control. When I went to college, I was taught how to
program, but never learned about the various tools used in the
process. We did C programming and never use Makefiles. My son learned
Java, but never used Ant or Maven. And, of course, there was no
discussion at all about version control.

I'm going to make a slight recommendation. Even though this is a
Subversion list, I am a Subversion admin, I like Subversion, and I've
posted before why I think decentralized version control systems like
Git are not the best way to do every project, I would recommend that
you use a decentralized version control system like Git in your
particular case.

The reasons are quite simple: You probably have a lot to do in your
job, and you don't want to become a full time Subversion
administrator. If you have a small CS department, you'll have maybe
four instructors and 100 students. Every year, if all goes according
to plan, 1/4 of those students graduate, and another 1/4 enter as
freshmen. Just looking at the straight and narrow: You have 100 people
you have to track in your Subversion repository. And, every year, 25
of them leave and another 25 come in.

Plus, you are talking about a dozen classes. That's dozen classes will
have several projects, and several students in each project. However,
some of those students will have multiple classes, and have particular
projects in each of those classes they have to have permission on.
You'll be spending 40 hours each week simply adding new projects and
permissions. And, this is for just a very small CS department.

A decentralized version control system can make your life much
simpler. You create a repository, and in your repository, you'll only
accept changes from the instructors. In a decentralized system, the
instructors will create a sub-repository from your repository, and
they'll handle the student permissioning in their sub-repositories.

If a student checks in code to the instructor's repository and the
instructor takes the change and that instructor submits those changes
to your repository, you can take those changes too. Thus, the
student's work is now in your repository. However, if that student
tried to submit those changes directly to you, you'd reject them
because you will only take changes from your instructors. If a student
wants to make changes, they'll have to submit them to the instructor's
repository first.

Most of the acceptance and rejection of changes can even be automated,
so your time and effort on running your version control system is
minimal.

Distributed version control systems have a lot of issues: They
encourage developers to work in their own little world and present
last minute changes. Security can be an issue since developers are
free to share their "repositories" without the central owners knowing
what is going on. Distributed version control systems simply are a big
pain in small environments and in development that has to be
centralized (such as corporate development).

However, the big advantage of a distributed system is that you can
distribute the workload and issues down the line. You no longer have
to know what project each and every student is working on. Now, your
instructors can set that up.

On Mon, Feb 22, 2010 at 2:37 PM, Stephen Bloch  wrote:
> I want to get my undergraduate students in the habit of using svn, both for
> individual projects and for group projects.  I'd like to be able to create
> projects that belong to a whole class, and to an arbitrary subset of
> students, and to an individual student. And I'd like to be able to set up
> the repository once and for all so that I don't have to reorganize it every
> semester.  The usual "trunk/branches/tags" organization didn't seem
> appropriate, at least at the top level.  Any advice from people who have set
> up a system like this?
>
> I was thinking of something like this
> users
>        joe
>        bob
>        mary
>        etc.
> classes
>        cs160
>        cs171
>                thisproject
>                thatproject
>        cs172
>                theotherproject
>                thefourthproject
>        etc.
>
> Each student would have a directory within users, with full access to that
> directory.
> Each student would also have read access to the directory for each class the
> student was in, and write access to the directories for projects that the
> student is involved in.  The instructor of each class would have write
> access to the directory for that class.
>
> Is this really stupid?  Am I "not getting" SVN?
>
>
> Stephen Bloch
> sbl...@adelphi.edu
>
>



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

Automated Merging

[kd1]

Hi All,

 

For the last several months I've been working on a new project ... an
automated merging and branch management solutions designed for teams
that utilizing branches in their Subversion repositories.  MergeMagician
makes it much easier to manage multiple branches and keep them in sync
by automating the merge process between branches.

 

I'm at the point in the project where I'd like to get some people to try
it out.  If there's anyone that would be interested in taking a closer
look at it, please check out the web site http://www.mergemagician.com.
If you'd like to download it, shoot me an e-mail and I'll send you the
download link.

 

Thanks Everyone.

 

- Kevin Dietz

Timpani Software, Inc.

 

Re: Automated Merging

[Pat Farrell]

k...@timpanisoftware.com wrote:
> look at it, please check out the web site http://www.mergemagician.com. 
> If you'd like to download it, shoot me an e-mail and I'll send you the
> download link.

The website has some critical information missing. Before I look futher:

What license do you expect to use?
Is this FOSS? or commercial?

If you expect users/companies to pay for your product, this is close to
SPAM.

-- 
Pat Farrell
http://www.pfarrell.com/

SVN 1.6.x - Merge using sparse checkout resulting in tree conflicts

[Srinivas Kotla]

Hi,

Did anyone run into issues with merge resulting in tree conflicts when using 
sparse checkouts?

Some directories that were not checkedout in the working copy were marked as 
tree conflicts after the merge (local delete, incoming edit upon merge).

Thanks,
Srinivas Kotla | Configuration Management | BroadSoft | +1 240.364.5260 | 
sko...@broadsoft.com  | 
www.broadsoft.com

Re: SVN 1.6.x - Merge using sparse checkout resulting in tree conflicts

[Stefan Sperling]

On Mon, Feb 22, 2010 at 02:38:47PM -0800, Srinivas Kotla wrote:
> Hi,
> 
> Did anyone run into issues with merge resulting in tree conflicts when
> using sparse checkouts?
> 
> Some directories that were not checkedout in the working copy were
> marked as tree conflicts after the merge (local delete, incoming edit
> upon merge).

Either merge into a non-sparse working copy, or if you are happy
with the directories missing in your merge result (caution, this is
unusual and most likely *not* what you want) just mark the conflict
as resolved.

Stefan

RE: SVN 1.6.x - Merge using sparse checkout resulting in tree conflicts

[Srinivas Kotla]

Hi Stefan,

Thank you for you response.  Yes, I would be advising our developers to revert 
such changes after examining them.  But this seems to be a bug in the sense 
that tree conflicts are not differentiating the missing-due-to-sparse-checkout 
with missing-due-to-deletion.

And just to give a background, the reason we use sparse checkout is so that 
developers can save space and time by not checking out the projects they don't 
need.  But need to merge from trunk from time to time to stay current.  

Thanks.

Srinivas Kotla | Configuration Management | BroadSoft | +1 240.364.5260 | 
sko...@broadsoft.com  | www.broadsoft.com


-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Monday, February 22, 2010 5:51 PM
To: Srinivas Kotla
Cc: users@subversion.apache.org
Subject: Re: SVN 1.6.x - Merge using sparse checkout resulting in tree conflicts

On Mon, Feb 22, 2010 at 02:38:47PM -0800, Srinivas Kotla wrote:
> Hi,
> 
> Did anyone run into issues with merge resulting in tree conflicts when
> using sparse checkouts?
> 
> Some directories that were not checkedout in the working copy were
> marked as tree conflicts after the merge (local delete, incoming edit
> upon merge).

Either merge into a non-sparse working copy, or if you are happy
with the directories missing in your merge result (caution, this is
unusual and most likely *not* what you want) just mark the conflict
as resolved.

Stefan

RE: Automated Merging

[Thomas Loy]

Although I can't speak for the poster, this looks to be commercial software.  A 
look at the parent website shows another build product for $1995 per server.  
Could be a useful tool, but since it isn't open source I doubt we'll take a 
close look at it since Build Engineering is at the bottom of the money food 
chain.

Cheers,
 
Tom Loy


-Original Message-
From: Pat Farrell [mailto:pfarr...@pfarrell.com] 
Sent: Monday, February 22, 2010 4:57 PM
Cc: users@subversion.apache.org
Subject: Re: Automated Merging

k...@timpanisoftware.com wrote:
> look at it, please check out the web site http://www.mergemagician.com. 
> If you'd like to download it, shoot me an e-mail and I'll send you the
> download link.

The website has some critical information missing. Before I look futher:

What license do you expect to use?
Is this FOSS? or commercial?

If you expect users/companies to pay for your product, this is close to
SPAM.

-- 
Pat Farrell
http://www.pfarrell.com/

new repo organization and merging advice needed

[Mark Branson]

I'm setting up a new SVN repository with some colleagues and wanted to get some 
expert feedback on how to best organize it as well as some ideas for merging 
strategies.  First off I should say that I'm a beginner/intermediate SVN user 
for a different and much smaller project, so I'm just getting my feet wet with 
branches and tags and the like.

This new subversion repo will contain code for three separate computer models 
written in fortran 90, but the third model is a merged version of the first 
two.  I'll call the first larger model AAA, the second smaller model BBB, and 
the merged model CCC.  AAA contains many, many subdirs, and effectively CCC is 
a carbon-copy of AAA but it has a new subdir sd3 to hold most of the contents 
of BBB along with a few other related changes.  The source tree of CCC looks 
something like:

  source/
subdir1/
subdir2/
subdir3/
  sd1/
  sd2/
  sd3/   <-- will contain the BBB source code 
subdir4/

But there's a few caveats:
1) Only about 50% of the source files from BBB get placed into sd3.
2) Some the BBB source files that are placed into the sd3 subdir require some 
coding changes that facilitate BBB becoming a module of CCC.
3) The file extensions are different.  BBB source files extensions are .f90, 
while everything in AAA and CCC are .F90.

And there are some other smaller changes necessary to the AAA source routines 
outside of subdir sd3 that are needed to create CCC.

The future development line will consist of some folks who will create branches 
within CCC that will get merged back to the trunk.  There will also be other 
developers updating BBB and then subsequently creating updated versions of CCC. 
 And we may at times be merging updated AAA versions to also make new versions 
of CCC, although this will be much less frequent.

I guess the "big" question is:  Is there any way to automate (or partially 
automate) the series of steps necessary to merge model BBB into CCC within 
Subversion itself?  Or am I stuck with using patch files?  I'm aware of the 
concept of externals in SVN, but since subdir sd3 is not an exact mirror of 
model BBB I wasn't certain if this would work or not.  Secondly, will the 
choice of how we arrange the subversion layout facilitate the merging of AAA + 
BBB to CCC in any way?  i.e., do we want three separate repos for AAA, BBB and 
CCC or just set them up as three separate projects within the same repo?

Thanks!
Mark Branson

A question about hook

[hu . miao1]

   hi,I want to catch the client ip in svn hook.How to do! Thanks.




ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and are 
not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the originator of the 
message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

Re: A question about hook

[Ryan Schmidt]

On Feb 22, 2010, at 18:56, hu.mi...@zte.com.cn wrote:

>   hi,I want to catch the client ip in svn hook.How to do! Thanks.

As far as I know, the client IP address is not available to the hook script.

If you are serving with Apache, the client IP will be in the Apache log; you 
may be able to make use of that.

Re: Regarding shallow checkouts

[An Me]

Hi

Thanks for the reply.

But usually if we are working on java project,to edit some files mean we
need to co the whole project and not that single file alone for editing as
we need to check whether the whole project is working fine by finally
compiling and running the same.So where exactly is the shallow co useful?

Regards,
An

On Mon, Feb 22, 2010 at 9:54 PM, Andrey Repin  wrote:

> Greetings, An Me!
>
> > I am learning svn and am a new-bie.The following is my doubt.
>
> > What is the significance of shallow checkouts.?.
> > Why would somebody want to checkout a project partially.?
> > If possible please explain with a scenario/real life example.
>
> If by shallow checkout you mean fetching of only certain depth of subdirs,
> then "real-world" example is quite simple.
> You need to change only one file. You co empty top-level directory, then
> update only that file. And edit and commit it.
>
>
> --
> WBR,
>  Andrey Repin (anrdae...@freemail.ru) 22.02.2010, <19:22>
>
> Sorry for my terrible english...
>
>

Re: Regarding shallow checkouts

[Ryan Schmidt]

On Feb 22, 2010, at 22:48, An Me wrote:

> On Mon, Feb 22, 2010 at 9:54 PM, Andrey Repin wrote:
> 
>> You need to change only one file. You co empty top-level directory, then
>> update only that file. And edit and commit it.
> 
> But usually if we are working on java project,to edit some files mean we need 
> to co the whole project and not that single file alone for editing as we need 
> to check whether the whole project is working fine by finally compiling and 
> running the same.So where exactly is the shallow co useful?

Maybe it is not useful for you. It might not be applicable to all workflows. It 
can be very useful for example if you have a web site in Subversion and need to 
only fix a typo on a single page. Or if you are an artist working on a game and 
only need to check out the graphics you are currently editing, and don't need 
all the other graphics or sounds or game code.


Personally, I use shallow checkouts for some types of changes in MacPorts. 
MacPorts is a package management system for Mac OS X written in Tcl. Each port 
is represented by a Tcl file that defines certain variables like the port name, 
version, category, and so on. Each port file lives in a directory with the name 
of the port, which lives in a directory with the name of the category. For 
example our php5 port lives in trunk/dports/lang/php5/Portfile. You can browse 
the tree here:

http://trac.macports.org/browser/trunk/dports

Now suppose I want to change a port's category, as I did for php5 in r49690 
when I moved it to the lang category from the www category because it is in 
fact a language and not limited to web programming:

http://trac.macports.org/changeset/49690

How could I do this? I could do it with URLs:

svn mv \
http://svn.macosforge.org/repository/macports/trunk/dports/www/php5 \
http://svn.macosforge.org/repository/macports/trunk/dports/lang \
-m "move php5 from www to lang category"

But the category is also listed in the port file itself. If I just move the 
port's directory to the new category's directory without also editing the port 
file, the port file will still say the port is in the www category while the 
port directory is in the lang category directory. That won't do. I need to edit 
the port file at the same time as I move its directory. I could check out the 
entire dports directory, but if I don't plan to use that directory for other 
purposes later, it would be wasteful to check out all 6000+ ports just for this 
small rearrangement. It's more efficient to check out sparsely. I might use:

svn co -N http://svn.macosforge.org/repository/macports/trunk/dports
cd dports
svn up -N www lang
svn up www/php5
svn mv www/php5 lang
# now edit the categories definition in lang/php5/Portfile
svn ci -m "move php5 from www to lang category"

Yes, the syntax I show above is the old pre-Subversion 1.5 non-recursive 
checkout syntax instead of the new Subversion 1.5+ sparse checkout syntax, but 
only because I have not yet bothered to learn the latter.

Re: Regarding shallow checkouts

[An Me]

Hi All,

Thank you all for the response.

Regards,
An
On Tue, Feb 23, 2010 at 11:23 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

>
> On Feb 22, 2010, at 22:48, An Me wrote:
>
> > On Mon, Feb 22, 2010 at 9:54 PM, Andrey Repin wrote:
> >
> >> You need to change only one file. You co empty top-level directory, then
> >> update only that file. And edit and commit it.
> >
> > But usually if we are working on java project,to edit some files mean we
> need to co the whole project and not that single file alone for editing as
> we need to check whether the whole project is working fine by finally
> compiling and running the same.So where exactly is the shallow co useful?
>
> Maybe it is not useful for you. It might not be applicable to all
> workflows. It can be very useful for example if you have a web site in
> Subversion and need to only fix a typo on a single page. Or if you are an
> artist working on a game and only need to check out the graphics you are
> currently editing, and don't need all the other graphics or sounds or game
> code.
>
>
> Personally, I use shallow checkouts for some types of changes in MacPorts.
> MacPorts is a package management system for Mac OS X written in Tcl. Each
> port is represented by a Tcl file that defines certain variables like the
> port name, version, category, and so on. Each port file lives in a directory
> with the name of the port, which lives in a directory with the name of the
> category. For example our php5 port lives in
> trunk/dports/lang/php5/Portfile. You can browse the tree here:
>
> http://trac.macports.org/browser/trunk/dports
>
> Now suppose I want to change a port's category, as I did for php5 in r49690
> when I moved it to the lang category from the www category because it is in
> fact a language and not limited to web programming:
>
> http://trac.macports.org/changeset/49690
>
> How could I do this? I could do it with URLs:
>
> svn mv \
> http://svn.macosforge.org/repository/macports/trunk/dports/www/php5 \
> http://svn.macosforge.org/repository/macports/trunk/dports/lang \
> -m "move php5 from www to lang category"
>
> But the category is also listed in the port file itself. If I just move the
> port's directory to the new category's directory without also editing the
> port file, the port file will still say the port is in the www category
> while the port directory is in the lang category directory. That won't do. I
> need to edit the port file at the same time as I move its directory. I could
> check out the entire dports directory, but if I don't plan to use that
> directory for other purposes later, it would be wasteful to check out all
> 6000+ ports just for this small rearrangement. It's more efficient to check
> out sparsely. I might use:
>
> svn co -N http://svn.macosforge.org/repository/macports/trunk/dports
> cd dports
> svn up -N www lang
> svn up www/php5
> svn mv www/php5 lang
> # now edit the categories definition in lang/php5/Portfile
> svn ci -m "move php5 from www to lang category"
>
> Yes, the syntax I show above is the old pre-Subversion 1.5 non-recursive
> checkout syntax instead of the new Subversion 1.5+ sparse checkout syntax,
> but only because I have not yet bothered to learn the latter.
>
>
>