[users] [Suggestion] Subversion 1.7

[Brandon Ooi]

Hi guys,

I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.

I believe this affects:

subversion
subversion-devel
subversion-javahl
subversion-perl
subversion-ruby
mod_dav_svn

Thanks again! Someday soon I hope to be a repoforge contributor.

Brandon Ooi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20111021/b0f3d3cf/attachment.html

[Nico Kadel-Garcia]

Post by Brandon Ooi
Hi guys,
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.
subversion
subversion-devel
subversion-javahl
subversion-perl
subversion-ruby
mod_dav_svn
Thanks again! Someday soon I hope to be a?repoforge?contributor.
Brandon Ooi

They're substantial. I've actually got the structure tested for
release candidates.

It's also dangerous in a mixed environment, much as 1.6 and 1.6 were,
because a working copy, once upgraded, is unusable with the old
software.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia

Post by Brandon Ooi
Hi guys,
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.

They're substantial. I've actually got the structure tested for
release candidates.

I am afraid this is not going to happen soon unless someone contributes
a working / tested patch. We're all really overloaded at the moment.

Post by Nico Kadel-Garcia
It's also dangerous in a mixed environment, much as 1.6 and 1.6 were,
because a working copy, once upgraded, is unusable with the old
software.

It seems that now upgrade is a manual step and un-upgraded working
copies can still be used with 1.6- in the future, so we shouldn't really
worry about that:

Upgrading the Working Copy

Subversion 1.7 introduces substantial changes to the working copy
format. In previous releases of Subversion, Subversion would
automatically update the working copy to the new format when a write
operation was performed. Subversion 1.7, however, will make this a
manual step. Before using Subversion 1.7 with their working copies,
users will be required to run a new command, svn upgrade to update the
metadata to the new format.

[Nico Kadel-Garcia]

Post by Yury V. Zaytsev

Post by Nico Kadel-Garcia

Post by Brandon Ooi
Hi guys,
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.

They're substantial. I've actually got the structure tested for
release candidates.

I am afraid this is not going to happen soon unless someone contributes
a working / tested patch. We're all really overloaded at the moment.

Post by Nico Kadel-Garcia
It's also dangerous in a mixed environment, much as 1.6 and 1.6 were,
because a working copy, once upgraded, is unusable with the old
software.

It seems that now upgrade is a manual step and un-upgraded working
copies can still be used with 1.6- in the future, so we shouldn't really
Upgrading the Working Copy
Subversion 1.7 introduces substantial changes to the working copy
format. In previous releases of Subversion, Subversion would
automatically update the working copy to the new format when a write
operation was performed. Subversion 1.7, however, will make this a
manual step. Before using Subversion 1.7 with their working copies,
users will be required to run a new command, svn upgrade to update the
metadata to the new format.

Well, *that's* a change.

I tried to upload my working patches to Comcast's user website, and
went slightly nuts with the bad interface. Does anyone have a semi
public FTP upload I can drop an SRPM or patch list in for access to
our repo owners?

I also believe that 1.7.1 just got tagged, but I have a day job and am
not going after that yet.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
I tried to upload my working patches to Comcast's user website, and
went slightly nuts with the bad interface. Does anyone have a semi
public FTP upload I can drop an SRPM or patch list in for access to
our repo owners?

What's the problem with forking our repository at github, adding your
patches there and submitting a pull request (other than that it will
take awhile until we can process it :-/ ) ?

[Nico Kadel-Garcia]

Post by Yury V. Zaytsev

Post by Nico Kadel-Garcia
I tried to upload my working patches to Comcast's user website, and
went slightly nuts with the bad interface. Does anyone have a semi
public FTP upload I can drop an SRPM or patch list in for access to
our repo owners?

What's the problem with forking our repository at github, adding your
patches there and submitting a pull request (other than that it will
take awhile until we can process it :-/ ) ?

It's a substantial rewrite. I've not tried pushing things to github
projects, other than to submit distinct patches. I'll look into it.

[Nico Kadel-Garcia]

Post by Yury V. Zaytsev

Post by Nico Kadel-Garcia
I tried to upload my working patches to Comcast's user website, and
went slightly nuts with the bad interface. Does anyone have a semi
public FTP upload I can drop an SRPM or patch list in for access to
our repo owners?

What's the problem with forking our repository at github, adding your
patches there and submitting a pull request (other than that it will
take awhile until we can process it :-/ ) ?

It's a substantial rewrite. I've not tried pushing things to github
projects, other than to submit distinct patches. I'll look into it.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia
I tried to upload my working patches to Comcast's user website, and
went slightly nuts with the bad interface. Does anyone have a semi
public FTP upload I can drop an SRPM or patch list in for access to
our repo owners?

What's the problem with forking our repository at github, adding your
patches there and submitting a pull request (other than that it will
take awhile until we can process it :-/ ) ?

[Nico Kadel-Garcia]

Post by Yury V. Zaytsev

Post by Nico Kadel-Garcia

Post by Brandon Ooi
Hi guys,
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.

They're substantial. I've actually got the structure tested for
release candidates.

I am afraid this is not going to happen soon unless someone contributes
a working / tested patch. We're all really overloaded at the moment.

Post by Nico Kadel-Garcia
It's also dangerous in a mixed environment, much as 1.6 and 1.6 were,
because a working copy, once upgraded, is unusable with the old
software.

It seems that now upgrade is a manual step and un-upgraded working
copies can still be used with 1.6- in the future, so we shouldn't really
Upgrading the Working Copy
Subversion 1.7 introduces substantial changes to the working copy
format. In previous releases of Subversion, Subversion would
automatically update the working copy to the new format when a write
operation was performed. Subversion 1.7, however, will make this a
manual step. Before using Subversion 1.7 with their working copies,
users will be required to run a new command, svn upgrade to update the
metadata to the new format.

Well, *that's* a change.

I tried to upload my working patches to Comcast's user website, and
went slightly nuts with the bad interface. Does anyone have a semi
public FTP upload I can drop an SRPM or patch list in for access to
our repo owners?

I also believe that 1.7.1 just got tagged, but I have a day job and am
not going after that yet.

[Yury V. Zaytsev]

Post by Nico Kadel-Garcia

Post by Brandon Ooi
Hi guys,
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.

They're substantial. I've actually got the structure tested for
release candidates.

I am afraid this is not going to happen soon unless someone contributes
a working / tested patch. We're all really overloaded at the moment.

Post by Nico Kadel-Garcia
It's also dangerous in a mixed environment, much as 1.6 and 1.6 were,
because a working copy, once upgraded, is unusable with the old
software.

It seems that now upgrade is a manual step and un-upgraded working
copies can still be used with 1.6- in the future, so we shouldn't really
worry about that:

Upgrading the Working Copy

Subversion 1.7 introduces substantial changes to the working copy
format. In previous releases of Subversion, Subversion would
automatically update the working copy to the new format when a write
operation was performed. Subversion 1.7, however, will make this a
manual step. Before using Subversion 1.7 with their working copies,
users will be required to run a new command, svn upgrade to update the
metadata to the new format.

[Yury V. Zaytsev]

Post by Brandon Ooi
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it
does seem like the requirements have not changed.

In the mean time I filed an issue:

https://github.com/repoforge/rpms/issues/78

[Brandon Ooi]

Hi guys,

I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.

I believe this affects:

subversion
subversion-devel
subversion-javahl
subversion-perl
subversion-ruby
mod_dav_svn

Thanks again! Someday soon I hope to be a repoforge contributor.

Brandon Ooi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20111021/b0f3d3cf/attachment-0002.html>

[Nico Kadel-Garcia]

Post by Brandon Ooi
Hi guys,
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it does
seem like the requirements have not changed.
subversion
subversion-devel
subversion-javahl
subversion-perl
subversion-ruby
mod_dav_svn
Thanks again! Someday soon I hope to be a?repoforge?contributor.
Brandon Ooi

They're substantial. I've actually got the structure tested for
release candidates.

It's also dangerous in a mixed environment, much as 1.6 and 1.6 were,
because a working copy, once upgraded, is unusable with the old
software.

[Yury V. Zaytsev]

Post by Brandon Ooi
I was wondering if we could see a new build of subversion 1.7. I don't
believe it to be substantially different than subversion 1.6 and it
does seem like the requirements have not changed.

In the mean time I filed an issue:

https://github.com/repoforge/rpms/issues/78