You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Saulius Grazulis <gr...@akl.lt> on 2005/03/27 09:32:13 UTC
Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
On Saturday 26 March 2005 15:36, Josh Pieper wrote:
> Congratulations, you have discovered a bug in FSFS. Fortunately, it
> was only in the parsing routines, so your repository is fully intact.
> The bug has been fixed in r13683 of Subversion's trunk and will
> hopefully be backported to a 1.1.x release. In the meantime, I'm
> sending you privately a link to a fully functional dump of your
> repository.
>
> Sorry for the trouble it has caused you,
> Josh
Great to hear this, I am impressed how fast the things get fixed here! :)
Now, I am a bit worried about my repositories since I use FSFS, but I am
currently running Phil's text-time branch (r13350q), and we are very happy
with this functionality and rely on it.
Now, staying on this branch, I will obviously miss your fix which I, ehh,
would not like.
Is there a chance that meta-data-versioning gets merged into the trunk, or do
I need to merge it into my copy? The problem with merging is that it starts
generating conflicts that need to be fixed manually, an the more the trunk
changes, the more conflicts will emerge...
I guess meta-data-versioning is quite usefull to many, and seems pretty stable
at the moment.
How should one proceed in such case?
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by Saulius Grazulis <gr...@akl.lt>.
On Sunday 27 March 2005 12:34, John Szakmeister wrote:
> > Now, I am a bit worried about my repositories since I use FSFS, but I
> > am currently running Phil's text-time branch (r13350q), and we are very
> > happy with this functionality and rely on it.
>
> Don't worry much. It's pretty rare to see the this condition.
Thanks for the message. Sounds reassuring :).
> IIRC, Phil will be merging changes from trunk on roughly a weekly basis.
> This is so that when it's time to merge, all the conflicts will already
> have been taken care of. This is enforced in any way, so he may take a
> little longer, or perform it at a different interval.
Aha, so Phil will get the fix into text-time somewhere during the next week or
two, right?
> If you feel the need to have it *right now*, then you should probably
> merge the change in yourself. Just watch out for when he does the weekly
> sync, so you can revert your change before updating, and avoid
> conflicting.
Clear. I will have a look. Since, as you say, the problem manifests itself
seldomly, and we keep frequent backups of our repositories, I will probably
wait till Phil's changes appears in the fixed trunk, or download the patched
text-time banched. I will probably mess more things up than I fix by trying a
merge without properly understanding the code ;).
>
> HTH.
Thanks for the info, its very helpful.
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by John Szakmeister <jo...@szakmeister.net>.
On Sunday 27 March 2005 04:32, Saulius Grazulis wrote:
[snip]
> Great to hear this, I am impressed how fast the things get fixed here!
> :)
>
> Now, I am a bit worried about my repositories since I use FSFS, but I
> am currently running Phil's text-time branch (r13350q), and we are very
> happy with this functionality and rely on it.
Don't worry much. It's pretty rare to see the this condition.
> Now, staying on this branch, I will obviously miss your fix which I,
> ehh, would not like.
>
> Is there a chance that meta-data-versioning gets merged into the trunk,
> or do I need to merge it into my copy? The problem with merging is that
> it starts generating conflicts that need to be fixed manually, an the
> more the trunk changes, the more conflicts will emerge...
>
> I guess meta-data-versioning is quite usefull to many, and seems pretty
> stable at the moment.
>
> How should one proceed in such case?
IIRC, Phil will be merging changes from trunk on roughly a weekly basis.
This is so that when it's time to merge, all the conflicts will already
have been taken care of. This is enforced in any way, so he may take a
little longer, or perform it at a different interval.
If you feel the need to have it *right now*, then you should probably
merge the change in yourself. Just watch out for when he does the weekly
sync, so you can revert your change before updating, and avoid
conflicting.
HTH.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 28 March 2005 12:32, Max Bowsher wrote:
> The main problem is in the way you have presented this change, going very
> much against the conventions of the project. We want Subversion to be
> designed, not just grown in an ad-hoc manner.
Well, I had slept much better two years ago if someone of the core developers
had taken my hand and tell me how to implement that.
But as you've been very busy (which is understandable) all I got was some
discussion *what* should be done (and not done) - not a single trace of
*how*.
And when Branko wrote
> Whenever you write a patch. :-)
I did just that, as I needed that feature.
That's the beauty of open source - just scratch your personal itch, and all
will be fine.
Summary: It's grown and not designed, because there was nobody to help me
designing it.
> I have seen that someone else
> has already asked you to post information on the *design* of the feature to
> dev@. The point is, we want to agree on the design *independent* of the
> code. Unless you summarize the design, someone will have to
> reverse-engineer a design description from your code - which takes time and
> effort - and most committers time and effort is focused on getting 1.2 out
> the door right now.
Well, maybe I'm not the best judge, but for me (as an innocent bystander in
most of svn's code) the patch looks fairly trivial.
But that's not enough. I'll try to write a better (longer) summary.
> And 1.2.1, etc., would be patch releases - bugfix only, no new features.
>
> > (Same for the full meta-data-versioning; it has changes in the same
> > locations
> > as text-time, only the property names and uses are different).
>
> No way, owner-group-mode is *much* more complicated. For instance, does it
> protect the text-base file similarly?
As soon as .svn is 0700, yes :-)
But of course, there are several points which will have to be addressed.
> Ah, so you have seen that email.
>
> It helps a bit, but leaves much unanswered.
> For example... does it cover switch too? What value do you use with "svn
> propset"? And posting it as a brief mention in an unrelated mail to users@
> is no good - people on dev@ need to see it.
Sorry. I've been out-of-office. I just saw that mail before leaving for
holiday and answered from home. I'll never to that again, I promise :-)
And as the code is grown and not designed :-), I don't have an answer for the
"switch" case, as I don't use that very often - so it's just not tested. (But
I believe that it should work; and if not, it's sufficient to define
svn:text-time as a base-changing property, like svn:eol-style)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Monday 28 March 2005 12:32, Max Bowsher wrote:
> The main problem is in the way you have presented this change, going very
> much against the conventions of the project. We want Subversion to be
> designed, not just grown in an ad-hoc manner.
Well, I had slept much better two years ago if someone of the core developers
had taken my hand and tell me how to implement that.
But as you've been very busy (which is understandable) all I got was some
discussion *what* should be done (and not done) - not a single trace of
*how*.
And when Branko wrote
> Whenever you write a patch. :-)
I did just that, as I needed that feature.
That's the beauty of open source - just scratch your personal itch, and all
will be fine.
Summary: It's grown and not designed, because there was nobody to help me
designing it.
> I have seen that someone else
> has already asked you to post information on the *design* of the feature to
> dev@. The point is, we want to agree on the design *independent* of the
> code. Unless you summarize the design, someone will have to
> reverse-engineer a design description from your code - which takes time and
> effort - and most committers time and effort is focused on getting 1.2 out
> the door right now.
Well, maybe I'm not the best judge, but for me (as an innocent bystander in
most of svn's code) the patch looks fairly trivial.
But that's not enough. I'll try to write a better (longer) summary.
> And 1.2.1, etc., would be patch releases - bugfix only, no new features.
>
> > (Same for the full meta-data-versioning; it has changes in the same
> > locations
> > as text-time, only the property names and uses are different).
>
> No way, owner-group-mode is *much* more complicated. For instance, does it
> protect the text-base file similarly?
As soon as .svn is 0700, yes :-)
But of course, there are several points which will have to be addressed.
> Ah, so you have seen that email.
>
> It helps a bit, but leaves much unanswered.
> For example... does it cover switch too? What value do you use with "svn
> propset"? And posting it as a brief mention in an unrelated mail to users@
> is no good - people on dev@ need to see it.
Sorry. I've been out-of-office. I just saw that mail before leaving for
holiday and answered from home. I'll never to that again, I promise :-)
And as the code is grown and not designed :-), I don't have an answer for the
"switch" case, as I don't use that very often - so it's just not tested. (But
I believe that it should work; and if not, it's sufficient to define
svn:text-time as a base-changing property, like svn:eol-style)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by Max Bowsher <ma...@ukf.net>.
philipp.marek@bmlv.gv.at wrote:
> Max Bowsher wrote:
>> Seemingly stable or not, it's still just a candidate patch.
>> You've backed yourself into an unpleasant corner here, relying on a
>> feature
>> that is still quite some way from integration.
>>
>> Even worse, you are using a branch based on trunk, which we do NOT
>> recommend for production use.
> Well, I had patches off the latest stable release, but was asked to work
> off
> trunk - now I read that basing on trunk is not recommended :-)
Not recommended for users.
Developers need to work off trunk.
> Saulius, I'll send you a patch tomorrow that applies to the current trunk.
> Apply this to a trunk-checkout, and you'll be fine.
> (That's what my patches/ directory was for, you know =-/)
But we shouldn't be encouraging people to use trunk for production purposes.
Which was the main reason I removed patches/ in the first place.
> And BTW, how about merging at the text-time-branch for 1.2 or 1.2.1? If
> everybody who ever contacted me about this uses my branch, it should be
> very
> much tested by now.
The main problem is in the way you have presented this change, going very
much against the conventions of the project. We want Subversion to be
designed, not just grown in an ad-hoc manner. I have seen that someone else
has already asked you to post information on the *design* of the feature to
dev@. The point is, we want to agree on the design *independent* of the
code. Unless you summarize the design, someone will have to reverse-engineer
a design description from your code - which takes time and effort - and most
committers time and effort is focused on getting 1.2 out the door right now.
And 1.2.1, etc., would be patch releases - bugfix only, no new features.
> (Same for the full meta-data-versioning; it has changes in the same
> locations
> as text-time, only the property names and uses are different).
No way, owner-group-mode is *much* more complicated. For instance, does it
protect the text-base file similarly?
> And for the request about a design-document for my branches: does the old
> doc-patch at
> http://subversion.tigris.org/servlets/GetAttachment?list=dev&msgId=502715&attachId=2
> help? I know that is has not much details, but that's how it works.
> (Simple substitution of property values as commit/import time, using them
> for
> update/checkout/export)
Ah, so you have seen that email.
It helps a bit, but leaves much unanswered.
For example... does it cover switch too? What value do you use with "svn
propset"? And posting it as a brief mention in an unrelated mail to users@
is no good - people on dev@ need to see it.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by ph...@bmlv.gv.at.
Saulius Grazulis wrote:
> Great to hear this, I am impressed how fast the things get fixed here! :)
>
> Now, I am a bit worried about my repositories since I use FSFS, but I am
> currently running Phil's text-time branch (r13350q), and we are very happy
> with this functionality and rely on it.
>
> Now, staying on this branch, I will obviously miss your fix which I, ehh,
> would not like.
>
> Is there a chance that meta-data-versioning gets merged into the trunk, or do
> I need to merge it into my copy? The problem with merging is that it starts
> generating conflicts that need to be fixed manually, an the more the trunk
> changes, the more conflicts will emerge...
>
> I guess meta-data-versioning is quite usefull to many, and seems pretty
> stable
> at the moment.
>
> How should one proceed in such case?
As I'm using svk (for offline-support) it's just a "svk up -sm" for me to get
*locally* merged versions. Maybe that'd be a solution for you.
IIUC, I shall not merge my branches to trunk, as that would clutter the branch.
Max Bowsher wrote:
> Seemingly stable or not, it's still just a candidate patch.
> You've backed yourself into an unpleasant corner here, relying on a feature
> that is still quite some way from integration.
>
> Even worse, you are using a branch based on trunk, which we do NOT
> recommend for production use.
Well, I had patches off the latest stable release, but was asked to work off
trunk - now I read that basing on trunk is not recommended :-)
Saulius, I'll send you a patch tomorrow that applies to the current trunk.
Apply this to a trunk-checkout, and you'll be fine.
(That's what my patches/ directory was for, you know =-/)
Hope that helps!
And BTW, how about merging at the text-time-branch for 1.2 or 1.2.1? If
everybody who ever contacted me about this uses my branch, it should be very
much tested by now.
(Same for the full meta-data-versioning; it has changes in the same locations as
text-time, only the property names and uses are different).
And for the request about a design-document for my branches: does the old
doc-patch at
http://subversion.tigris.org/servlets/GetAttachment?list=dev&msgId=502715&attachId=2
help? I know that is has not much details, but that's how it works.
(Simple substitution of property values as commit/import time, using them for
update/checkout/export)
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Sunday 27 March 2005 11:32, Saulius Grazulis wrote:
> Now, I am a bit worried about my repositories since I use FSFS, but I am
> currently running Phil's text-time branch (r13350q), and we are very happy
> with this functionality and rely on it.
>
> Now, staying on this branch, I will obviously miss your fix which I, ehh,
> would not like.
>
> Is there a chance that meta-data-versioning gets merged into the trunk, or
> do I need to merge it into my copy? The problem with merging is that it
> starts generating conflicts that need to be fixed manually, an the more the
> trunk changes, the more conflicts will emerge...
>
> I guess meta-data-versioning is quite usefull to many, and seems pretty
> stable at the moment.
>
> How should one proceed in such case?
You could do this:
- cd into your trunk/
- call
svn merge --dry-run http://svn.collab.net/repos/svn/branches/meta-data-versioning/text-time/ -r 13255:HEAD .
(or whatever your access method is), and verify that no error happened.
Then call the same without --dry-run, and you'll have the newest
text-time-versioning with the newest trunk!
Hope that helps!
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by John Szakmeister <jo...@szakmeister.net>.
On Sunday 27 March 2005 09:29, Max Bowsher wrote:
[snip]
> John Szakmeister wrote:
> > IIRC, Phil will be merging changes from trunk on roughly a weekly
> > basis. This is so that when it's time to merge, all the conflicts
> > will already have been taken care of. This is enforced in any way,
> > so he may take a little longer, or perform it at a different
> > interval.
>
> Sorry, but in this case you remember incorrectly. The locking and ruby
> branches were undergoing periodic merges, but no others were.
> Moreover, I don't think the text-time branch should be undergoing
> merges at this point. Better that it remain quiet and contain just the
> relevant feature changes until a suitable amount of integration effort
> can be applied to it post-1.2.
Yep, you're right. I was think about the various merges that I saw, but
that was just cherry-picking particular revs. Sorry for the confusion.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by Saulius Grazulis <gr...@akl.lt>.
On Sunday 27 March 2005 16:29, Max Bowsher wrote:
> Seemingly stable or not, it's still just a candidate patch.
> You've backed yourself into an unpleasant corner here, relying on a feature
> that is still quite some way from integration.
Well, basically my question was what are the plans regarding this feature and
when will integration happen, so that I know how to plan our repositories,
and how to train my repository users.
We can go on working without this feature (and we were doing this for a while
already), but having it is _very_ handy :). Naturally, I am interested when
and if it will be integrated into the main trunk and release... ;).
> Even worse, you are using a branch based on trunk, which we do NOT
> recommend for production use.
Well, I just wanted to try it out, and I am happy that it works. It lets me
to play with the feature and gives a feeling if our problems get solved by
it.
Now I have two options to choose -- to maintain my own version of patched
branch (with all the problems solved by myself ;) or to wait until it finds
it's way into the main trunk or official release (which I will probably do).
If the merge into the trunk would happen in the next few months, I would
probably start using the feature on the spot, with the text-time branch, and
upgrade to official release as soon as it appears.
If there merge is more than a half a year away, I will probably stick with the
official release.
> If you really need this feature, you need to assume the burden of applying
> these changes to whatever real release version you choose.
Sure.
Regards,
--
Saulius Gražulis
Visuomeninė organizacija "Atviras Kodas Lietuvai"
P.Vileišio g. 18
LT-10306 Vilnius
Lietuva (Lithuania)
tel/fax: (+370-5)-210 40 05
mobilus: (+370-684)-49802, (+370-614)-36366
Re: Including fixes to FSFS into meta-data-versioning? [Was: Re: PLEASE Help with Repository CORRUPTION!]
Posted by Max Bowsher <ma...@ukf.net>.
Saulius Grazulis wrote:
> On Saturday 26 March 2005 15:36, Josh Pieper wrote:
>
>> Congratulations, you have discovered a bug in FSFS. Fortunately, it
>> was only in the parsing routines, so your repository is fully intact.
>> The bug has been fixed in r13683 of Subversion's trunk and will
>> hopefully be backported to a 1.1.x release. In the meantime, I'm
>> sending you privately a link to a fully functional dump of your
>> repository.
>>
>> Sorry for the trouble it has caused you,
>> Josh
>
> Great to hear this, I am impressed how fast the things get fixed here! :)
>
> Now, I am a bit worried about my repositories since I use FSFS, but I am
> currently running Phil's text-time branch (r13350q), and we are very happy
> with this functionality and rely on it.
>
> Now, staying on this branch, I will obviously miss your fix which I, ehh,
> would not like.
>
> Is there a chance that meta-data-versioning gets merged into the trunk, or
> do
> I need to merge it into my copy? The problem with merging is that it
> starts
> generating conflicts that need to be fixed manually, an the more the trunk
> changes, the more conflicts will emerge...
>
> I guess meta-data-versioning is quite usefull to many, and seems pretty
> stable
> at the moment.
>
> How should one proceed in such case?
Seemingly stable or not, it's still just a candidate patch.
You've backed yourself into an unpleasant corner here, relying on a feature
that is still quite some way from integration.
Even worse, you are using a branch based on trunk, which we do NOT recommend
for production use.
If you really need this feature, you need to assume the burden of applying
these changes to whatever real release version you choose.
John Szakmeister wrote:
> IIRC, Phil will be merging changes from trunk on roughly a weekly basis.
> This is so that when it's time to merge, all the conflicts will already
> have been taken care of. This is enforced in any way, so he may take a
> little longer, or perform it at a different interval.
Sorry, but in this case you remember incorrectly. The locking and ruby
branches were undergoing periodic merges, but no others were.
Moreover, I don't think the text-time branch should be undergoing merges at
this point. Better that it remain quiet and contain just the relevant
feature changes until a suitable amount of integration effort can be applied
to it post-1.2.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org