You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels Janosch Hofmeyr <ne...@elego.de> on 2009/03/30 00:19:28 UTC
locking externals
Hi,
(Cc'ing TSVN because it's relevant to a mail on that list. This mail is
mainly directed at dev@subversion)
I'm investigating externals and found out that externals with a fixed
revision aren't locked as long as that fixed revision == HEAD.
While this may be a rare case for externals within the same repository, it
could be more common with (dir-)externals coming from another repos. Then
again, dir-externals need an explicit commit...
Anyway, it's rare but still wrong, right? In my elaborate reproduction
script (attached), this happens for both file- and dir-externals.
On svn.haxx.se, I only found a reference that trusts a fixed revision to
lock an external.
Should I add an issue for this?
Furthermore, I noticed that when I modify a fixed-revision external and
update, the modifications get "merged", causing a conflict for some strange
reason. Firstly, I think that conflict is probably erratic. Secondly, I'd
say svn should at least warn that something considered uncommittable was
modified, and maybe skip all "merge" attempts on a fixed revision external.
Should I add an issue for this, too/either?
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1475609
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Hyrum K. Wright wrote:
> On Apr 11, 2009, at 6:12 PM, Neels Janosch Hofmeyr wrote:
>> If we adhere to the 6 months schedule, 1.7 is in June. That's
>> roughly eight
>> weeks from now :P
>
> Huh? 1.6.0 shipped less than a month ago. Six months from March 20
> is Sept. 20, not June. I'm personally planning and hoping to have wc-
> ng code complete by the end of August, and hope to have wc-ng on trunk
> usable as the default within a month (though that may be optimistic).
Oh.
I thought it worked like the Ubuntu cycle has been so far, so that it's the
same month every year. Then again, Ubuntu releases on time.
But what's the use of a 6 months schedule if we drag each release,
effectively making it an 8.67 months schedule? People can't rely on that any
more than before, can they?
On the other hand it doesn't make sense to rush releases, shortening the
effective time between shipping one and kicking off the next release, so
that we're constantly busy releasing.
So maybe it would make sense to have a supposedly reliable date-fixed
schedule with a reasonable time period, say, 9 months, which takes into
account the time it takes to soak a number of release candidates...
Just thinking.
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1676293
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Apr 11, 2009, at 6:12 PM, Neels Janosch Hofmeyr wrote:
> Stefan Sperling wrote:
>> On Sat, Apr 11, 2009 at 12:18:44PM -0400, Mark Phippard wrote:
>>> On Fri, Apr 10, 2009 at 6:48 PM, Neels Janosch Hofmeyr <neels@elego.de
>>> > wrote:
>>>> Neels Janosch Hofmeyr wrote:
>>>>> Right, if no-one speaks up this time, I'll make two new issues.
>>>> Buddy system!
>>>>
>>>> Does anyone agree that these two are good to be issues?
>>>>
>>>> #1 externals with a fixed revision aren't locked for commit as
>>>> long as
>>>> that fixed revision coincides with HEAD.
>>>>
>>>> #2 when a file-external with a fixed revision is modified, the next
>>>> update causes a conflict with the (unrelated) HEAD revision.
>>>>
>>>> I am attaching a shell script that makes both of them happen, for
>>>> both file-
>>>> and directory externals.
>>> I agree these would be good changes. I suspect they will be
>>> difficult
>>> to implement. AFAIK, svn does not always even know you are
>>> working in
>>> an external. Especially when we are talking about folders. For
>>> example, if you run commands like svn st from your project root,
>>> then
>>> it knows that those folders and items are externals. But if you run
>>> the command from a folder down within the external, it no longer
>>> knows
>>> this. The only way the command line will commit externals is to do
>>> this. So you'd have to ask the command line code to always walk the
>>> tree to the root of the WC so that it could then discover if an item
>>> is an external. That seems like a risky change for a small benefit.
>>>
>>> Ideally, and perhaps the new WC will allow this?, the WC would just
>>> know that these items are externals and could handle them
>>> differently.
>>
>> Since externals probably won't be easy to fix in 1.6.x, I'd say it
>> makes sense to make these fixes in wc-ng, hopefully released in
>> 1.7.x.
>
> If we adhere to the 6 months schedule, 1.7 is in June. That's
> roughly eight
> weeks from now :P
Huh? 1.6.0 shipped less than a month ago. Six months from March 20
is Sept. 20, not June. I'm personally planning and hoping to have wc-
ng code complete by the end of August, and hope to have wc-ng on trunk
usable as the default within a month (though that may be optimistic).
>> And I'd rather see yet another dev get accustomed to wc-ng code
>> instead of trying to fix things in the ever-so-broken old libsvn_wc.
>>
>> Stefan
>
> It seems that currently, pretty much anything I look at is said to
> be better
> with wc-ng. So far I always agreed, but it starts to feel a little
> eerie by
> now.
wc-ng is *not* a panacea, but the storage model is vastly superior to
what we've got now. For instance, each node (file, directory, etc)
will know to which repository it references, so an external is simply
a node which references a repository different from it's parent.
Pretty simple to represent, and it should be easy for somebody to come
along and write the higher-level piece which use that information.
> We should post a request that wc-ng should make it cheap to know
> whether any
> WC node is (part of) an external and whether that external has an
> explicit
> revision number pinned on it in its definition.
>
> BTW, do we have a wc-ng newsticker? ;)
I don't know about a newsticker ("new sticker" or "news ticker"? :P),
but it would be nice to have a place to collect these "oh, wc-ng will
fix that" issues that come up frequently. We've got a meta-issue in
the issue tracker, as well as notes/wc-ng-design. Perhaps one of
those will be suitable?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1658959
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Stefan Sperling wrote:
> On Sat, Apr 11, 2009 at 12:18:44PM -0400, Mark Phippard wrote:
>> On Fri, Apr 10, 2009 at 6:48 PM, Neels Janosch Hofmeyr <ne...@elego.de> wrote:
>>> Neels Janosch Hofmeyr wrote:
>>>> Right, if no-one speaks up this time, I'll make two new issues.
>>> Buddy system!
>>>
>>> Does anyone agree that these two are good to be issues?
>>>
>>> #1 externals with a fixed revision aren't locked for commit as long as
>>> that fixed revision coincides with HEAD.
>>>
>>> #2 when a file-external with a fixed revision is modified, the next
>>> update causes a conflict with the (unrelated) HEAD revision.
>>>
>>> I am attaching a shell script that makes both of them happen, for both file-
>>> and directory externals.
>> I agree these would be good changes. I suspect they will be difficult
>> to implement. AFAIK, svn does not always even know you are working in
>> an external. Especially when we are talking about folders. For
>> example, if you run commands like svn st from your project root, then
>> it knows that those folders and items are externals. But if you run
>> the command from a folder down within the external, it no longer knows
>> this. The only way the command line will commit externals is to do
>> this. So you'd have to ask the command line code to always walk the
>> tree to the root of the WC so that it could then discover if an item
>> is an external. That seems like a risky change for a small benefit.
>>
>> Ideally, and perhaps the new WC will allow this?, the WC would just
>> know that these items are externals and could handle them differently.
>
> Since externals probably won't be easy to fix in 1.6.x, I'd say it
> makes sense to make these fixes in wc-ng, hopefully released in 1.7.x.
If we adhere to the 6 months schedule, 1.7 is in June. That's roughly eight
weeks from now :P
>
> And I'd rather see yet another dev get accustomed to wc-ng code
> instead of trying to fix things in the ever-so-broken old libsvn_wc.
>
> Stefan
It seems that currently, pretty much anything I look at is said to be better
with wc-ng. So far I always agreed, but it starts to feel a little eerie by
now.
We should post a request that wc-ng should make it cheap to know whether any
WC node is (part of) an external and whether that external has an explicit
revision number pinned on it in its definition.
BTW, do we have a wc-ng newsticker? ;)
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1657125
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by Mark Phippard <ma...@gmail.com>.
On Sat, Apr 11, 2009 at 12:56 PM, Stefan Sperling <st...@elego.de> wrote:
> On Sat, Apr 11, 2009 at 12:18:44PM -0400, Mark Phippard wrote:
>> On Fri, Apr 10, 2009 at 6:48 PM, Neels Janosch Hofmeyr <ne...@elego.de> wrote:
>> > Neels Janosch Hofmeyr wrote:
>> >> Right, if no-one speaks up this time, I'll make two new issues.
>> > Buddy system!
>> >
>> > Does anyone agree that these two are good to be issues?
>> >
>> > #1 externals with a fixed revision aren't locked for commit as long as
>> > that fixed revision coincides with HEAD.
>> >
>> > #2 when a file-external with a fixed revision is modified, the next
>> > update causes a conflict with the (unrelated) HEAD revision.
>> >
>> > I am attaching a shell script that makes both of them happen, for both file-
>> > and directory externals.
>>
>> I agree these would be good changes. I suspect they will be difficult
>> to implement. AFAIK, svn does not always even know you are working in
>> an external. Especially when we are talking about folders. For
>> example, if you run commands like svn st from your project root, then
>> it knows that those folders and items are externals. But if you run
>> the command from a folder down within the external, it no longer knows
>> this. The only way the command line will commit externals is to do
>> this. So you'd have to ask the command line code to always walk the
>> tree to the root of the WC so that it could then discover if an item
>> is an external. That seems like a risky change for a small benefit.
>>
>> Ideally, and perhaps the new WC will allow this?, the WC would just
>> know that these items are externals and could handle them differently.
>
> Since externals probably won't be easy to fix in 1.6.x, I'd say it
> makes sense to make these fixes in wc-ng, hopefully released in 1.7.x.
>
> And I'd rather see yet another dev get accustomed to wc-ng code
> instead of trying to fix things in the ever-so-broken old libsvn_wc.
+1. These "fixes" would be pretty borderline candidates for backport anyway.
I think it'd be great to see someone give externals some love rather
than just talk about how we need something new to replace them and
then never do it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1652166
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Apr 11, 2009 at 12:18:44PM -0400, Mark Phippard wrote:
> On Fri, Apr 10, 2009 at 6:48 PM, Neels Janosch Hofmeyr <ne...@elego.de> wrote:
> > Neels Janosch Hofmeyr wrote:
> >> Right, if no-one speaks up this time, I'll make two new issues.
> > Buddy system!
> >
> > Does anyone agree that these two are good to be issues?
> >
> > #1 externals with a fixed revision aren't locked for commit as long as
> > that fixed revision coincides with HEAD.
> >
> > #2 when a file-external with a fixed revision is modified, the next
> > update causes a conflict with the (unrelated) HEAD revision.
> >
> > I am attaching a shell script that makes both of them happen, for both file-
> > and directory externals.
>
> I agree these would be good changes. I suspect they will be difficult
> to implement. AFAIK, svn does not always even know you are working in
> an external. Especially when we are talking about folders. For
> example, if you run commands like svn st from your project root, then
> it knows that those folders and items are externals. But if you run
> the command from a folder down within the external, it no longer knows
> this. The only way the command line will commit externals is to do
> this. So you'd have to ask the command line code to always walk the
> tree to the root of the WC so that it could then discover if an item
> is an external. That seems like a risky change for a small benefit.
>
> Ideally, and perhaps the new WC will allow this?, the WC would just
> know that these items are externals and could handle them differently.
Since externals probably won't be easy to fix in 1.6.x, I'd say it
makes sense to make these fixes in wc-ng, hopefully released in 1.7.x.
And I'd rather see yet another dev get accustomed to wc-ng code
instead of trying to fix things in the ever-so-broken old libsvn_wc.
Stefan
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Apr 10, 2009 at 6:48 PM, Neels Janosch Hofmeyr <ne...@elego.de> wrote:
> Neels Janosch Hofmeyr wrote:
>> Right, if no-one speaks up this time, I'll make two new issues.
> Buddy system!
>
> Does anyone agree that these two are good to be issues?
>
> #1 externals with a fixed revision aren't locked for commit as long as
> that fixed revision coincides with HEAD.
>
> #2 when a file-external with a fixed revision is modified, the next
> update causes a conflict with the (unrelated) HEAD revision.
>
> I am attaching a shell script that makes both of them happen, for both file-
> and directory externals.
I agree these would be good changes. I suspect they will be difficult
to implement. AFAIK, svn does not always even know you are working in
an external. Especially when we are talking about folders. For
example, if you run commands like svn st from your project root, then
it knows that those folders and items are externals. But if you run
the command from a folder down within the external, it no longer knows
this. The only way the command line will commit externals is to do
this. So you'd have to ask the command line code to always walk the
tree to the root of the WC so that it could then discover if an item
is an external. That seems like a risky change for a small benefit.
Ideally, and perhaps the new WC will allow this?, the WC would just
know that these items are externals and could handle them differently.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1651557
Re: buddy for two externals issues? -- was: Re: locking externals
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Issue #3401 corresponds to #1 described in this mail:
Neels Janosch Hofmeyr wrote:
> Neels Janosch Hofmeyr wrote:
>> Right, if no-one speaks up this time, I'll make two new issues.
> Buddy system!
>
> Does anyone agree that these two are good to be issues?
>
> #1 externals with a fixed revision aren't locked for commit as long as
> that fixed revision coincides with HEAD.
>
[...]
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1637476
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1735993
buddy for two externals issues? -- was: Re: locking externals
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Neels Janosch Hofmeyr wrote:
> Right, if no-one speaks up this time, I'll make two new issues.
Buddy system!
Does anyone agree that these two are good to be issues?
#1 externals with a fixed revision aren't locked for commit as long as
that fixed revision coincides with HEAD.
#2 when a file-external with a fixed revision is modified, the next
update causes a conflict with the (unrelated) HEAD revision.
I am attaching a shell script that makes both of them happen, for both file-
and directory externals.
The output of interest is:
#1
pin/file.r3 is a file external fixated on revision 3:
[[[
+ svn ci -m 'repos2, r4!?' pin/file.r3
Sending pin/file.r3
Transmitting file data .
Committed revision 4.
+ echo 'Wait! file.r3 is supposed to stay at -r3!'
Wait! file.r3 is supposed to stay at -r3!
+ echo 'The commit went through because the external was at HEAD.'
]]]
pin/dir.r2 is a directory external fixated at revision 2:
[[[
+ svn ci -m 'repos 1, r3!?' pin/dir.r2
Sending pin/dir.r2/alpha
Transmitting file data .
Committed revision 3.
]]]
(This commit was also accepted, which is bad.)
If the external's revision is smaller than HEAD, a commit invariably fails
with "out of date" messages, which is good. But, commit handling probably
needs another explicit check to block externals with fixed revs, so that
they act coherently and don't change behaviour just because the HEAD
revision number changed.
#2
The file external fixated at revision 1 ends up being merged with HEAD (here
revision 4).
[[[
+ echo whoops
+ cat pin/file.r1
r1
whoops
+ svn st pin/file.r1
M X pin/file.r1
+ svn up pin/file.r1
Conflict discovered in 'pin/file.r1'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
C pin/file.r1
Updated to revision 4.
Summary of conflicts:
Text conflicts: 1
+ cat pin/file.r1
<<<<<<< .mine
r1
whoops
=======
whoops
>>>>>>> .r4
]]]
Same thing for modified file beta within dir-external dir.r1, which is
fixated at revision 1, HEAD is r3 here:
[[[
+ echo whoops
+ cat pin/dir.r1/beta
r1
whoops
+ svn st pin/dir.r1/beta
M pin/dir.r1/beta
+ svn up pin/dir.r1/beta
Conflict discovered in 'pin/dir.r1/beta'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
C pin/dir.r1/beta
Updated to revision 3.
Summary of conflicts:
Text conflicts: 1
+ cat pin/dir.r1/beta
<<<<<<< .mine
r1
whoops
=======
r2
>>>>>>> .r3
]]]
(-r3 still says "r2" because the test didn't change it for -r3. This is not
the error. The problem is that ">>> .r3" indicates it was tried to be
updated to -r3 in spite of the external's request for -r1.)
I need a buddy to confirm these.
Thanks,
~Neels
>
> Neels Janosch Hofmeyr wrote:
>> Hi,
>>
>> (Cc'ing TSVN because it's relevant to a mail on that list. This mail is
>> mainly directed at dev@subversion)
>>
>> I'm investigating externals and found out that externals with a fixed
>> revision aren't locked as long as that fixed revision == HEAD.
>>
>> While this may be a rare case for externals within the same repository, it
>> could be more common with (dir-)externals coming from another repos. Then
>> again, dir-externals need an explicit commit...
>>
>> Anyway, it's rare but still wrong, right? In my elaborate reproduction
>> script (attached), this happens for both file- and dir-externals.
>>
>> On svn.haxx.se, I only found a reference that trusts a fixed revision to
>> lock an external.
>>
>> Should I add an issue for this?
>>
>>
>> Furthermore, I noticed that when I modify a fixed-revision external and
>> update, the modifications get "merged", causing a conflict for some strange
>> reason. Firstly, I think that conflict is probably erratic. Secondly, I'd
>> say svn should at least warn that something considered uncommittable was
>> modified, and maybe skip all "merge" attempts on a fixed revision external.
>>
>> Should I add an issue for this, too/either?
>>
>> ~Neels
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1475609
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1537328
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1637476
Re: locking externals
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Right, if no-one speaks up this time, I'll make two new issues.
~Neels
Neels Janosch Hofmeyr wrote:
> Hi,
>
> (Cc'ing TSVN because it's relevant to a mail on that list. This mail is
> mainly directed at dev@subversion)
>
> I'm investigating externals and found out that externals with a fixed
> revision aren't locked as long as that fixed revision == HEAD.
>
> While this may be a rare case for externals within the same repository, it
> could be more common with (dir-)externals coming from another repos. Then
> again, dir-externals need an explicit commit...
>
> Anyway, it's rare but still wrong, right? In my elaborate reproduction
> script (attached), this happens for both file- and dir-externals.
>
> On svn.haxx.se, I only found a reference that trusts a fixed revision to
> lock an external.
>
> Should I add an issue for this?
>
>
> Furthermore, I noticed that when I modify a fixed-revision external and
> update, the modifications get "merged", causing a conflict for some strange
> reason. Firstly, I think that conflict is probably erratic. Secondly, I'd
> say svn should at least warn that something considered uncommittable was
> modified, and maybe skip all "merge" attempts on a fixed revision external.
>
> Should I add an issue for this, too/either?
>
> ~Neels
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1475609
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1537328