On Thu, Mar 1, 2012 at 6:18 AM, Leo Razoumov <[email protected]> wrote:
> Brian,
> for simplicity you might want to follow the selection rules that
> already exist in fossil web-interface.
> When I go to the web-interface=>Branches and select a branch I am
> presented with a partial view of the DAG that fossil thinks is
> relevant to the branch I chose. For the sake of consistency I would
> prefer that limsync push/pull uses the same selection rules and
> transfers the same commits.
>
Note that there are a several of ways to view check-ins related to a
branch. For example:
http://www.fossil-scm.org/fossil/timeline?r=experimental
http://www.fossil-scm.org/fossil/timeline?r=experimental&mionly
http://www.fossil-scm.org/fossil/timeline?t=experimental
>
> To transfer individual commits it would be great if --pushtags and
> --pulltags accept SHA1 hashes in addition to actual tag names.
>
> As a next step, I hope, one can augment limsync with a json API so
> that power users can do more complex things.
>
> --Leo--
>
> P.S. Sorry for top-posting.
>
> On Wed, Feb 29, 2012 at 21:32, Brian Smith <[email protected]> wrote:
> > Hello again,
> >
> > Ok, so, it's not quite afternoon, but, it's still the same day.
> >
> > Here are some of the basic items that need feedback:
> > I've marked each question with an asterisk (*) so that you can find my
> > questions easier.
> >
> > Scenario:
> > You're pulling a specific branch (topic1) that other developers are also
> > committing on.
> > You have only ever pulled topic1 branch and nothing else.
> >
> > Someone commits to topic1 and then later moves that commit to the mistake
> > branch.
> >
> > As presently implemented, limsync will pull in the control artifact that
> > made that change,
> > and that commit will then show up in your copy on the mistake branch,
> even
> > though you've
> > never pulled mistake.
> >
> > (*) What do people want to have happen here? I think this is reasonable
> > behavior because,
> > the movement of a commit off of the branch you're interactive with is a
> > valid part of the
> > history of that branch. I don't yet know what it would take to change
> that
> > behavior.
> >
> >
> > Scenario:
> > Same as above.
> >
> > Someone merges into topic1 the branch topic2.
> >
> > As presently implemented, limsync will pull in the merge commit, and the
> > last commit to
> > topic2, but no other commits. It's necessary to at least pull in every
> > immediate parent of
> > a merge commit, but, it only needs to be the manifests. File data could
> be
> > excluded.
> > It's possible to have limsync pull in the complete history of topic2 on
> such
> > an event.
> >
> > (*) What would people prefer to see with respect to merge commits?
> > I suppose this could be configurable behavior, but, I'm hesitant to make
> it
> > configurable
> > on the first pass. That should be added later based on demand, probably.
> >
> > Scenario:
> > Same as before.
> >
> > Someone creates a new branch topic3 off of some commit of topic1.
> >
> > limsync currently will pull in the first commit of that new branch.
> > Mind you, only the _first_ commit will be pulled in. I don't yet know
> how it
> > interacts
> > with the command 'branch new'. I'll add that to my list of things to test
> > regardless.
> >
> > (*) Does anyone have any preference here? I could probably make it ignore
> > new branches
> > off of the branches you're pulling, but, it seems to me that discovering
> new
> > lines of history
> > is valuable.
> >
> > That's it for the behavior questions.
> >
> > I have a couple user interface and functionality questions as well that
> > could be
> > helpful to get feedback on. Though, if nobody has any immediate
> preferences,
> > I'll just go ahead and do whatever I want. :)
> >
> > Right now, the command line interface is modeled like so (ignoring
> existing
> > flags):
> >
> > fossil push/pull [--tickets] [--wiki] [--branch NAME]*
> >
> > Plus two advanced flags: --pushtags, --pulltags which allow you to
> specify
> > any arbitrary
> > tag name. All of --tickets, --wiki, and --branch, are essentially
> > implemented in terms of
> > those two flags.
> >
> > --branch, --pushtags, and --pulltags can all be specified multiple times
> > like so:
> >
> > fossil push --branch topic1 --branch topic2
> >
> > (*) Would people prefer a comma separated list of branches/tags ?
> >
> > (*) Would it be useful to anyone to be able to specify something like:
> >
> > fossil pull --tag release=v1.0
> >
> > So that you could theoretically create repositories that only track tags
> > with specific values?
> >
> > That's it for now. As I put my head back into the code, I'm sure I'll
> come
> > up with other questions.
> >
> > -B
> >
> > On Wednesday, February 29, 2012 at 12:22 PM, Brian Smith wrote:
> >
> > Hi,
> >
> > Sorry for my radio silence over the weekend.
> > I have to say, I'm a tad caught off guard by the sudden enthusiasm for
> this
> > feature!
> >
> > Anyway, what I need most is community feedback on some open questions.
> > You can find most of my open questions in the fossil-dev archives.
> > (Unfortunately, it looks like you need to sign up for that list to see
> > them.)
> >
> > Right now, I need to do some other work, but, I'll try to carve out some
> > time this
> > afternoon to summarize the open questions and give an overview of what
> I'd
> > like
> > to push into a branch on the master repo once the feature has more
> testing.
> >
> > -B
> >
> > On Saturday, February 25, 2012 at 7:37 PM, Leo Razoumov wrote:
> >
> > On Sat, Feb 25, 2012 at 21:30, Jan Danielsson
> > <[email protected]> wrote:
> >
> > On 02/26/12 03:09, [email protected] wrote:
> >
> > Why not just productize limsync?
> >
> >
> > Going by what Brian Smith has written, it's a question of having time
> > do work on it and handling a few special cases.
> >
> > Brian, if you need any kind of assistance, please let us know. I
> > really want this feature.
> >
> >
> > I also offered my help to Brian in limsync testing. Right now limsync
> > still has some bugs. For instance, attempts to pull trunk from main
> > fossil repo into limsync repo stops well short of its leaf. On the
> > other hand, when ready limsync should be very useful.
> >
> > --Leo--
> > _______________________________________________
> > fossil-users mailing list
> > [email protected]
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> >
> >
> >
> > _______________________________________________
> > fossil-users mailing list
> > [email protected]
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> _______________________________________________
> fossil-users mailing list
> [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard Hipp
[email protected]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
