Mark J. Nelson wrote:
>> Up-to-date webrev against ON clone is here:
>> http://cr.opensolaris.org/~vkotal/webrev-better_upload.onnv.final/
>
> The new line 276 isn't very informative about what the parenthesized
> number means. (Ie the number of args received when 1 was expected.)
I remove
Mark J. Nelson wrote:
> Vladimir Kotal wrote:
>> Vladimir Kotal wrote:
>>> Hi all,
>>>
>>> Based on feedback from Dan Price, I've changed webrev.sh a bit to
>>> make it more pleasant to work with (in terms of webrev upload) and to
>>
Vladimir Kotal wrote:
> Hi all,
>
> Based on feedback from Dan Price, I've changed webrev.sh a bit to make
> it more pleasant to work with (in terms of webrev upload) and to fix 2
> small bugs.
>
> webrev is here:
>http://cr.opensolaris.org/~vkotal/webre
Rafael Vanoni wrote:
> Vladimir Kotal wrote:
>> Hi all,
>>
>> Based on feedback from Dan Price, I've changed webrev.sh a bit to make
>> it more pleasant to work with (in terms of webrev upload) and to fix 2
>> small bugs.
>>
>> webrev is he
Hi all,
Based on feedback from Dan Price, I've changed webrev.sh a bit to make
it more pleasant to work with (in terms of webrev upload) and to fix 2
small bugs.
webrev is here:
http://cr.opensolaris.org/~vkotal/webrev-better_upload.onnv/
v.
Mark J. Nelson wrote:
> I don't have any other comments.
>
After expanding the set of test cases and doing retesting I have bumped
into interesting feature of ksh (and a bug in the script):
#!/usr/bin/ksh
fce1()
{
typeset -r host_spec=$1
}
fce2()
{
typeset -r host_spec=$1
}
fc
Mark J. Nelson wrote:
>>> webrev is here:
>>>http://cr.opensolaris.org/~vkotal/webrev_delete-6771203.onnv/
>
> The date in the .TH section of the manpage should be updated.
grr, I always forget to update this one. fixed.
> webrev.sh:
> 171, 236: When do you ever call this inappropriately?
This one still needs code reviewers. Again, anyone bored or with
ksh/webrev mindset can take a look.
Thanks,
v.
> webrev is here:
>http://cr.opensolaris.org/~vkotal/webrev_delete-6771203.onnv/
Hi all,
webrev upload might be nice but sometimes it is necessary to un-clobber
the webrev area or do a sync from scratch (additions/removals of files
in repo). To be able to do so without sftp(1), I've reused already
existing functionality in webrev.sh and made it available via new option -D.
Hello again in this thread,
A little heads up for anyone who will be changing webrev.sh in
substantial way (adding/removing command line options):
As Darren (Cc'ed) mentioned in CR 6751994, adding an option to webrev.sh
should be accompanied by change in cdm.py:cmdtable. Unfortunately, there
Running the tests and reading the man page changes again I realized
there is an aspect of webrev behavior which might not be obvious:
'webrev -U' will store the webrev to local directory named "webrev" and
upload it to remote host with directory name equal to dirname of local
workspace/reposit
John Plocher wrote:
> I'm not a webrev expert, but here's a few nits...
>
> usr/src/tools/scripts/webrev.1:
> 371 For custom remote targets, -t option allows to specify all
> components:
>
> Better: -t option allows one to provide a completely specified upload
> target
>
> Q: Does
Hi all again,
This review request is still missing code reviewers. If someone feels
bored or even interested, please take a look:
http://cr.opensolaris.org/~vkotal/webrev_upload.onnv/
Thanks,
v.
Vladimir Kotal wrote:
> $ webrev -O -p original_webrev \
> -o $CODEMGR_WS/incremental_webrev -U
>
> will upload the webrev to this location:
>http://cr.opensolaris.org/incremental_webrev/
Of course I rather meant:
http://cr.opensolaris.org/~OSOL_USERNAME/incremental_webrev/
v.
Vladimir Kotal wrote:
> Vladimir Kotal wrote:
>
>
>
>> The webrev has been updated to include code which implements the above:
>>http://cr.opensolaris.org/~vkotal/webrev_upload.onnv/
>
> Just to give an idea of the capabilities of current version here
Vladimir Kotal wrote:
> The webrev has been updated to include code which implements the above:
>http://cr.opensolaris.org/~vkotal/webrev_upload.onnv/
Just to give an idea of the capabilities of current version here is the
list of "unit tests":
positive:
- SSH
web
Danek Duvall wrote:
> On Fri, Sep 26, 2008 at 03:01:20PM +0200, Vladimir Kotal wrote:
>
>> - rsync user with remote host
>>webrev -r -U -h some_host.org
>>
>> - rsync user with custom directory
>>(local file-system copy, just for demonstration)
>&
Gordon Ross wrote:
>> ???> Also, usually we do not want to upload non-OSol webrevs to
>>> cr.opensolaris.org which also speaks for current state of the code (on
>>> the other hand, the upload-trigger option can be limited to -O, sigh).
>> I pretty much never publish a webrev without intervening s
Dan Price wrote:
> I would suggest that upload be enabled via a separate flag.
Already done (after Shawn's e-mail) as -U flag.
> -O was really intended to be an ON specific hack, when I added it.
> Some consolidations (like packaging and the installer) are using
> defect.opensolaris.org and -O
Mark J. Nelson wrote:
> I pretty much never publish a webrev without intervening steps. Those
> include, variously: examining it, chmod'ing it, renaming it, adding
> comments, rewriting and/or modifying index.html files, massaging file
> comments and/or bug links.
>
> That sounds like a ton
Shawn Walker wrote:
> Personally, I generate them to look at them first. After I'm certain I
> haven't missed anything, then I upload them.
okay. Thinking about it for a little more, it makes sense to follow the
classic UNIX school and have extra option for the upload trigger.
webrev refresh
Vladimir Kotal wrote:
> new webrev is here:
>http://cr.opensolaris.org/~vkotal/webrev_upload.onnv/
For potential reviewers: I am little bit torn between upload by default
with -O and having an option to trigger the upload.
It's the question of statistics - for most of the time
Richard Lowe wrote:
> Vladimir Kotal writes:
>
>> Hi all,
>>
>> http://cr.opensolaris.org/ asks for help:
>>Auto-post to the site from webrev
>>
>> Instead of doing it from webrev.sh itself, why not to solve 2 things at
>> once [*] by doing
Mark J. Nelson wrote:
>
>
>>> Can we have webrev integrated into Cadmium so one can run 'hg webrev' as
>>> was possible with wx, please ?
>>
>> Just typing "webrev" does the right thing.
>
> Which means "exactly what it would do if it were part of cadmium." In
> this particular case, anyway.
>
Hi all,
http://cr.opensolaris.org/ asks for help:
Auto-post to the site from webrev
Instead of doing it from webrev.sh itself, why not to solve 2 things at
once [*] by doing it from Cadmium ?
webrev is here:
http://cr.opensolaris.org/~vkotal/webrev_upload.onnv/
I failed to find any CR r
Richard Lowe wrote:
> Vladimir Kotal writes:
>
>> James C. McPherson wrote:
>>> I don't know when the two repos will merge, though, so perhaps
>>> it might be best to just wait a bit.
>> okay, will wait. (The plan with onnv-transition repository is t
Vladimir Marek wrote:
> That's true. But you don't need to recommit all the time. Just before
> final putback should be fine. If you commit often in your workspace, it
You missed my point - I need to recommit after each code review
iteration for webrev refreshment since generally code reviewer
James Carlson wrote:
> Why not go to the build workspace and just pull from the desktop
> workspace? Pulls are pretty fast, even over large distances (quite a
> change from Teamware, even with nifty things like turbo_flp).
Like this ?
+-+ pull +-+ pull +---
Richard Lowe wrote:
> I'd imagine, given the above, that you're using backup/restore to move
> changes between machines? If so, why would you do that rather than
Exactly. My workstation sits under my desk in Europe and has only 2 CPUs
so nightly takes forever to complete (besides, the machine
Vladimir Kotal wrote:
> Hi all,
>
> lib/python/onbld/Scm/Backup.py does backup of .hg/hgrc which contains
> the path to parent. This breaks things if backup repository uses local
> clone and restore repository another local clone (model where sparse
> builds are done locall
Hi all,
lib/python/onbld/Scm/Backup.py does backup of .hg/hgrc which contains
the path to parent. This breaks things if backup repository uses local
clone and restore repository another local clone (model where sparse
builds are done locally and nightlies on build machine e.g. in another
geo
Richard Lowe wrote:
> Vladimir Kotal writes:
>> or something more complicated ?
>>
>> Don't know why but any addition to the customized file does not have
>> any effect on 'hg outgoing -v' output. In fact, there is no attempt to
>> open the s
Richard Lowe wrote:
> Vladimir Kotal writes:
>
>> Vladimir Kotal wrote:
>>
>>
>>
>>>> It is, jmcp asked me about this last night too. You can adjust the
>>>> style to insert \n's after each file.
>>> Any example on ho
Vladimir Kotal wrote:
>> It is, jmcp asked me about this last night too. You can adjust the
>> style to insert \n's after each file.
>
> Any example on how to achieve that ?
It's possible to hack Mercurial and Cadmium to do that but it is not nice:
0. ena
Richard Lowe wrote:
> Right, list' is a cdm command, it's printing out what cdm knows.
> 'outgoing' is from Hg, and doesn't need to go as far as cdm does.
Interesting, it would seem just the opposite given that cdm is built
atop hg modules. On the other hand it seems logical since 'hg outgoing
Richard Lowe wrote:
> It's probably preserving the rename (which is what 'workspace filerm'
> and 'wx rm' effectively do), rather than special casing deleted_files
> into an 'hg rm'.
>
> You should not re-create deleted_files in a mercurial gate.
so the 'deleted_files' directory in the gate is
Hi all,
It looks like wx2hg converts files deleted in Teamware workspace as
added files in Mercurial workspace (added to 'deleted_files' directory).
e.g. part of the following 'hg list' snippet:
---
added:
deleted_files/usr/src/cmd/ssh/include/strsep.h (renamed from
usr/src/cmd/ssh/i
Hi all,
Can we have webrev integrated into Cadmium so one can run 'hg webrev' as
was possible with wx, please ?
v.
James C. McPherson wrote:
> Hi Vladimir,
Hi James,
> Cadmium does have that functionality, but I'm not sure if
> it's been pushed into the hg ON repo yet. If you pull the
> scm-migration "onnv-transition" repo
> (ssh://anon at hg.opensolaris.org/hg/scm-migration/onnv-transition)
> then you s
Hi all,
Again, this is nice example of doing too-late-catch-up.
Previously wx(1) offered to suppress cstyle/rti/... warnings via
$CODEMGR_WS/wx/*.NOT files. This does not seem to be possible with
Cadmium (according to e.g. lib/python/onbld/Checks/CStyle.py). Or the
functionality is there but
Linda Bernal wrote:
> - In the meantime we will point folks to the scm-migration alias for all
> questions.
This means scm-migration-dev@ or different mailing list ? (I don't see
scm-migration@ listed on http://mail.opensolaris.org/mailman/listinfo/)
v.
Richard Lowe wrote:
> Mercurial doesn't have the concept of an active list, the 'hg list'
> output is all cdm. We use that list in recommit, it *must* be
> accurate.
Ah, that was the thing I was missing. Then cdm_recommit() can still use
the list acquired by 'wslist[repo].active(opts['parent'
Richard Lowe wrote:
> The basic theory "Cache things we're explicitly told, and run faster"
> holds, though with somewhat associated risk. The precise method
> outlined above falls flat. It is imperative the active list as seen
> by other things (think reci) is *correct*. Letting people influe
James Carlson wrote:
> It's not *that* bad when the cache is reasonably warm:
>
> % time hg status -mardn usr/src
> usr/src/uts/common/io/bridge/bridge.c
> 4.50u 2.03s 0:07.52 86.8%
> %
Is this file system cache or some kind of Mercurial cache ? If the
former then the limit of its helpfulnes
James Carlson wrote:
> Vladimir Kotal writes:
>>- 'hg edit' adds new entry
>
> I think that might be deferring a bit too much to SCCS. Mercurial
> (like CVS and a few others) is different. You don't have to "check
> out" files in order to ed
Dean Roehrich wrote:
> On Tue, Jul 29, 2008 at 03:57:52PM +0200, Vladimir Kotal wrote:
>> By 'behave like wx' I meant the following changes to cdm.py:
>>- 'hg add' hook is processed by cdm which leads to an entry being
>> created in plaintext file (
Richard Lowe wrote:
>>> 1. simple, just fix it
I have taken care of that (CR 6726003).
>>> 2. rewrite Cadmium [1] to behave like wx
>
> Somewhat, but not quite. I think we could possibly achieve something
> similar, but "like wx" is far too strong for how similar we possibly
> could be.
By
> SCM Migration Project Tool Usage Survey
Warning: my answers are really boring.
> What tools have you used from the SCM Migration Project?
webrev, nightly, wx (edit, backup, restore, webrev)
> http://opensolaris.org/os/project/scm-migration/
>
> When was the last time you used them?
Yesterda
48 matches
Mail list logo
