Re: [Monotone-devel] Re: mtn:// sync
Hi, Stephen Leake wrote: Logically, those are not branches; they are now part of mainline. So it would be more correct to say : I don't quite follow your reasoning here. Even if they got merged later on, those are still branches of development. You will get revisions that used to be on a branch but are now on mainline. Their branch cert didn't change. Even after a merge, most revisions of the branch will still carry only *one* branch cert - that of the branch. Thus I fail to see how those should now be on mainline. You'd only save sync'ing 'new' development branches. Which is a good thing. Really? If I'm interested enough in a project to want to fetch it's development history (!), I'm at least as interested in all current branches, as I am interested in history. I've never taken the effort to strip away branches I might not be interested in (heck, how should I even know?). But that's just me. Let's hear other people's preferences here! Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi,
Matthew Nicholson wrote:
I don't like this idea. One of the things I like about monotone is that
it does not force you to think like its developers think when it comes
to naming branches. As a side note, I do like '.' as a branch
separator, but not the reverse domain name prefixes (I think some sort
of namespace support would be better).
Thanks for your feedback. Maybe we need to be more careful about what
characters to allow and what not for branch names. We certainly have to
allow '-' in branch names, yes.
However, for me, branches have always had a hierarchy, and I could tell
monotone to display that hierarchy by choosing proper branch names. But
monotone not making use of that hierarchy feels wrong to me. And you
don't seem to be opposing to a branch hierarchy, just against
hard-wiring that to reverse domain name prefixes, right? That's fine
with me.
I don't think making net.venge.monotone mean
{net.venge.monotone,net.venge.monotone.*} is a good idea either. When I
ask for net.venge.monotone that is what I want, not it and all of its
children.
Really?
Well, you will get those branches which have been propagated back as
well, anyway. You'd only save sync'ing 'new' development branches.
If I want all of its children, I can explicitly ask for those
too. In fact, I have never wanted all of its children.
Guess it's a matter of taste. I mostly want to sync a complete project.
Part of my point was, that you cannot easily sync 'a branch and all of
its children' correctly, because * matches anything. To be on the save
side, you currently have to say:
net.venge.monotone net.venge.monotone.*
(which would *not* match net.venge.monotone-foo, which I don't want,
because that's not a child branch of net.venge.monotone).
This would break some existing databases (mine being one)
Are you also using slashes '/' in your branch names, or only dashes '-'?
We certainly need to allow dashes, yes. Sorry for that, I just didn't
think too hard about it.
Slashes in branch names would make dumb support difficult. I'd still
vote for not allowing slashes in branch names.
Regards
Markus
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht [EMAIL PROTECTED] writes:
I don't think making net.venge.monotone mean
{net.venge.monotone,net.venge.monotone.*} is a good idea either.
When I ask for net.venge.monotone that is what I want, not it and
all of its children.
Really?
Well, you will get those branches which have been propagated back as
well, anyway.
Logically, those are not branches; they are now part of mainline. So
it would be more correct to say :
You will get revisions that used to be on a branch but are now on
mainline.
You'd only save sync'ing 'new' development branches.
Which is a good thing. I have examples/display_branches.lua installed,
so I get a count of revisions per branch. I can see deciding to only
pay attention to a subset of branches, or only to mainline, at some point.
The point is not _only_ to save time during sync, but also to avoid
logical clutter.
'ls branches' would be faster, and easier to sort thru, for example.
If I want all of its children, I can explicitly ask for those too.
In fact, I have never wanted all of its children.
Guess it's a matter of taste. I mostly want to sync a complete project.
Part of my point was, that you cannot easily sync 'a branch and all of
its children' correctly, because * matches anything. To be on the save
side, you currently have to say:
net.venge.monotone net.venge.monotone.*
That seems natural to me.
(which would *not* match net.venge.monotone-foo, which I don't want,
because that's not a child branch of net.venge.monotone).
That works for me as well.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht wrote: No, seriously, what's the problem you want to solve fundamentally? Are you saying you never want to download revision without it's certs? Yes (...without /all/ of its certs). I know that certs are loosely coupled to their respective revision. Nevertheless, it is unexpected to get, during a sync, a revision, and all its other certs, but not its branch certs (which in turn shows, that there must be some logic explicitly blocking them, because they are, in principle, not different from the other certs that are transmitted). Regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Derek Scherger wrote: Markus Schiltknecht wrote: Hi, Thomas Moschny wrote: Ok. I vaguely had in mind that there also was a non-technical reason. I don't know any non-technical reason. I believe it's a consequence of the invariant enforced by the database that no revision will be stored unless it's parents are also stored. This ultimately requires that all ancestry for a revision is in the local database before the revision can be stored. This is clear. But the question was, is there a non-technical reason to not sync the branch certs of these ancestor revisions? Regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi, Thomas Moschny wrote: Yes (...without /all/ of its certs). I know that certs are loosely coupled to their respective revision. Nevertheless, it is unexpected to get, during a sync, a revision, and all its other certs, but not its branch certs (which in turn shows, that there must be some logic explicitly blocking them, because they are, in principle, not different from the other certs that are transmitted). +1 I think nuskool (or netsync, but I'm more willing to implement that for the former) should transfer all certs (or maybe just all trusted certs) for each revision it sends, no matter what caused the revision to be sent initially. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi, Thomas Moschny wrote: Any time this comes up, I wonder again, what was the argument for including revs that are ancestors of revs you want to sync, but at then excluding their branch certs? I always found this counterintuitive. I think that's just an effect of how netsync works, with its separate merkle tries for certs and revisions. So to me, making net.venge.monotone mean net.venge.monotone.*, does look like an ugly hack to match user's expectations here without addressing the real issue. Making net.venge.monotone mean that branch and all of its children would result in fetching the associated certs as well, because all child branches were included. Thus I even think that would fix the silly issue you pointed out above, no? (For the common case of syncing net.venge.monotone, that is). Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
On Tuesday 25 March 2008, Markus Schiltknecht wrote: Thomas Moschny wrote: Any time this comes up, I wonder again, what was the argument for including revs that are ancestors of revs you want to sync, but at then excluding their branch certs? I always found this counterintuitive. I think that's just an effect of how netsync works, with its separate merkle tries for certs and revisions. Ok. I vaguely had in mind that there also was a non-technical reason. So to me, making net.venge.monotone mean net.venge.monotone.*, does look like an ugly hack to match user's expectations here without addressing the real issue. Making net.venge.monotone mean that branch and all of its children would result in fetching the associated certs as well, because all child branches were included. Thus I even think that would fix the silly issue you pointed out above, no? Exactly, but that's why I said it looks like an ugly hack. It fixes the problem accidentally, ... (For the common case of syncing net.venge.monotone, that is). ... and for a common usage pattern, but not fundamentally. Regards, Thomas -- Thomas Moschny [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi, Thomas Moschny wrote: Ok. I vaguely had in mind that there also was a non-technical reason. I don't know any non-technical reason. Exactly, but that's why I said it looks like an ugly hack. It fixes the problem accidentally, ... (For the common case of syncing net.venge.monotone, that is). ... and for a common usage pattern, but not fundamentally. The well known 80% solution. :-) No, seriously, what's the problem you want to solve fundamentally? Are you saying you never want to download revision without it's certs? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht wrote: Hi, Thomas Moschny wrote: Ok. I vaguely had in mind that there also was a non-technical reason. I don't know any non-technical reason. I believe it's a consequence of the invariant enforced by the database that no revision will be stored unless it's parents are also stored. This ultimately requires that all ancestry for a revision is in the local database before the revision can be stored. Exactly, but that's why I said it looks like an ugly hack. It fixes the problem accidentally, ... (For the common case of syncing net.venge.monotone, that is). ... and for a common usage pattern, but not fundamentally. The well known 80% solution. :-) No, seriously, what's the problem you want to solve fundamentally? Are you saying you never want to download revision without it's certs? Personally, I don't think that I want to receive a revision if I don't also get the certs. Mystery meat is how I would describe the situation where I get a rev but not its certs. i.e. I have no idea who committed the rev, when they committed it, what they had to say about it, etc. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
On Fri, 2008-03-21 at 09:58 +0100, Markus Schiltknecht wrote: Hi, Timothy Brownawell wrote: It will be in 0.40, Uh.. really? I personally don't feel there's a majority for such a syntax. But I might have missed some of the discussions. In my opinion, such an URL shouldn't ever be exposed to the user. Especially not when requiring shell and/or other kinds of escaping. It will be in addition to the current syntax, so what works now will still work. Yes, '' and especially '!' aren't good characters for shells. I think I'll use the suggestions of '/' and '-' instead (still in the query string instead of the path, so it'll work with file:// and ssh:// sync). This has been requested before, most recently for use in Debian package control files. ...I also neglected to put this on a separate branch, which in retrospect probably wasn't the best of ideas. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Hi, Timothy Brownawell wrote: It will be in addition to the current syntax, so what works now will still work. Okay, that's fine. Yes, '' and especially '!' aren't good characters for shells. I think I'll use the suggestions of '/' and '-' instead (still in the query string instead of the path, so it'll work with file:// and ssh:// sync). Yeah, that looks better for shells. However, I'm wondering somewhat how you want to find the end of the URL and beginning of include/exclude patterns. So, am I right in assuming we are talking about such URLs like these: * mtn://monotone.ca/net.venge.motonone* * mtn://monotone.ca/net.venge.motonone*-net.venge.monotone.experiment * file:/tmp/test.db/org.foo*/org.bar*-org.foo.unwanted/org.bar.unwanted Do we still need the asterisk? Quite a while ago, Lapo was complaining, that net.venge.monotone* would not only mean branches net.venge.monotone and net.venge.monotone.*, but also net.veneg.monotone-foo. That's a valid concern, IMO. Now, I know we didn't ever hardcode the dot as a branch name separator (IIRC). However, most people *are* using dot-separated branch names. And for policy branches - possibly also for nuskool - we should probably switch to enforce such a hierarchical branch naming anyway. So, I'm proposing to get rid of the asterisk entirely, making net.venge.monotone mean: that branch and net.venge.monotone.* (but not net.venge.monotone-foo. I'm assuming that's what you want most of the time anyway. If you really want to sync only net.venge.monotone and none of it's children, you'd have to explicitly exclude them. So it would look more like: * mtn://monotone.ca/net.venge.motonone Or for nvm only, excluding child branches: * mtn://monotone.ca/net.venge.motonone-net.venge.monotone.* As we need to change branch naming policies (prohibit use of '-' and '/') it seems like it's a good time for rethinking branch naming policies. Regarding the general direction of stuffing include/exclude patterns into the URL: most other DVCSen feature a single URL per branch - and people are getting used to that. Supporting such per-branch URLs from monotone is thus a good thing, IMO. However, the URL needs to look similarly sane. Just my $0.02. Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
Markus Schiltknecht wrote: So, I'm proposing to get rid of the asterisk entirely, making net.venge.monotone mean: that branch and net.venge.monotone.* (but not net.venge.monotone-foo. I'm assuming that's what you want most of +1 the time anyway. If you really want to sync only net.venge.monotone and none of it's children, you'd have to explicitly exclude them. So it The thing is, you are very likely going to get the children anyway, at least those that have been merged back so the only thing you'll be able to exclude are the branch certs themselves. I wonder if being able to exclude things like this is really worth he trouble since it often won't do what you might expect anyway. Regarding the general direction of stuffing include/exclude patterns into the URL: most other DVCSen feature a single URL per branch - and If we go with your suggestion above and drop the ability to exclude things we might be there too. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
On Fri, Mar 21, 2008 at 06:34:33AM -0500, Timothy Brownawell wrote: Yes, '' and especially '!' aren't good characters for shells. I think I'll use the suggestions of '/' and '-' instead (still in the query string instead of the path, so it'll work with file:// and ssh:// sync). There's one strong argument for sticking with standard URL syntax: the quoting issues are already solved. In particular, with the include= style there is a standard, obvious way to include branches that have characters like in them. It's not a *pretty* way, exactly, but existing deployment can beat purity. Also in an ideal world, people wouldn't have reason to keep using funky include/exclude patterns, so they would just set a string once (when they first pull) and then never touch it again, and so shell quoting issues wouldn't matter. But we're not in the world, so eh. -- Nathaniel -- Electrons find their paths in subtle ways. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtn:// sync
mtn sy monotone.ca nvm* --exclude nvm.experiment* would become mtn sy mtn://monotone.ca?nvm*!nvm.experiment* When will this change become available? Since I am currently only building monotone from the release source packages, I guess it will be in 0.40. Please correct me there. But I'd like to drop myself an note for remembering the new command syntax before blaming my machines in a few weeks, when 'suddenly' the old commands don't work anymore ;-) Another thing on this issue, are the documentations updated closely? Thanks, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: mtn:// sync
On Thu, 2008-03-20 at 18:43 +0100, Philipp Gröschler wrote: mtn sy monotone.ca nvm* --exclude nvm.experiment* would become mtn sy mtn://monotone.ca?nvm*!nvm.experiment* When will this change become available? Since I am currently only building monotone from the release source packages, I guess it will be in 0.40. Please correct me there. But I'd like to drop myself an note for remembering the new command syntax before blaming my machines in a few weeks, when 'suddenly' the old commands don't work anymore ;-) It will be in 0.40, but the old way will also work. Another thing on this issue, are the documentations updated closely? We try to keep the documentation up to date, but we do occasionally miss parts. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
